Embedded Systems Architecture

Design and write software for embedded devices to build safe and connected systems

Daniele Lacamera

BIRMINGHAM—MUMBAI

Embedded Systems Architecture

Copyright © 2023 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Gebin George

Publishing Product Manager: Kunal Sawant

Senior Editor: Rohit Singh

Technical Editor: Pradeep Sahu

Copy Editor: Safis Editing

Project Coordinator: Deeksha Thakkar

Proofreader: Safis Editing

Indexer: Sejal Dsilva

Production Designer: Joshua Misquitta

Developer Relations Marketing Executive: Sonakshi Bubbar

First published: May 2018

Second edition: January 2023

Production reference: 1281222

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80323-954-5

www.packt.com

Contributors

About the author

Daniele Lacamera is a software technologist and researcher. He is an expert in operating systems and TCP/IP, with more than 20 academic publications on transport protocol optimization. He began his career as a Linux kernel developer and had his first contribution accepted in Linux 2.6.

Since 2012, he has been working on microcontroller-based architectures, focusing on the design, development, and integration of software for embedded systems. He is an active contributor to many free software projects, and co-author of a TCP/IP stack and a POSIX operating system (OS) for Cortex-M devices, both distributed under the GPL. Nowadays, his activities are focused on IoT security, cryptography, secure boot, and custom transport protocols.

About the reviewer

Marco Oliverio obtained his Ph.D. degree at the University of Calabria, with a dissertation on OS defenses against side-channel and hardware attacks. Some of his academic publications have been presented at vitally important conferences regarding OSes. After finishing his Ph.D., he started working as a firmware and embedded developer, contributing to several open source projects.

Preface

Embedded systems have become increasingly popular in the last two decades thanks to the technological progress made by microelectronics manufacturers and designers, which has aimed to increase computing power and decrease the size of the logic of microprocessors and peripherals.

Designing, implementing, and integrating the software components for these systems requires a direct approach to the hardware functionalities in most cases, where tasks are implemented in a single thread and there is no operating system to provide abstractions to access CPU features and external peripherals. For this reason, embedded development is considered a domain on its own in the universe of software development, in which the developer’s approach and workflow need to be adapted accordingly.

This book briefly explains the hardware architecture of a typical embedded system, introduces the tools and methodologies needed to get started with the development of a target architecture, and then guides the readers through interaction with the system features and peripheral interaction. Some areas, such as energy efficiency and connectivity, are addressed in more detail to give a closer view of the techniques used to design low-power and connected systems. Later in the book, a more complex design, incorporating a (simplified) real-time operating system, is built from the bottom up, starting from the implementation of single system components. Finally, in this second edition, we have added a detailed analysis of the implementation of TrustZone-M, the TEE technology introduced by ARM as part of its latest family of embedded microcontrollers.

The discussion often focuses on specific security and safety mechanisms by suggesting specific technologies aimed at improving the robustness of the system against programming errors in the application code, or even malicious attempts to compromise its integrity.

Who this book is for

If you’re a software developer or designer that wants to learn about embedded programming, this is the book for you. You’ll also find this book useful if you’re a less experienced or a beginner embedded programmer willing to expand your knowledge of embedded systems. More experience embedded software engineers may find this book useful for refreshing their knowledge of the internals of device drivers, memory safety, secure data transfers, privilege separation, and secure execution domains.

What this book covers

Chapter 1, Embedded Systems – A Pragmatic Approach, is an introduction to microcontroller-based embedded systems. The scope of the book is identified, from a broader definition of “embedded systems” to the actual domain that will be analyzed – 32-bit microcontrollers with physical memory mapping.

Chapter 2, Work Environment and Workflow Optimization, outlines the tools used and the development workflow. This is an introduction to the toolchain, debuggers, and emulators that can be used to produce code in a binary format that can be uploaded and run on the target platform.

Chapter 3, Architectural Patterns, is all about the strategies and development methodologies for collaborative development and testing. This chapter proposes a description of the processes that are typically used while developing and testing software for embedded systems.

Chapter 4, The Boot-Up Procedure, analyzes the boot phase of an embedded system, boot stages, and bootloaders. It contains a detailed description of the bring-up code and the mechanisms used to separate the software into several boot stages.

Chapter 5, Memory Management, suggests some optimal strategies for memory management by pointing out common pitfalls and explaining how to avoid memory errors that can result in unpredictable or bad behavior in the application code.

Chapter 6, General-Purpose Peripherals, walks through accessing GPIO pins and other generic integrated peripherals. This is the first interaction of the target platform with the outside world, using electric signals to perform simple input/output operations.

Chapter 7, Local Bus Interfaces, guides you through the integration of serial bus controllers (UART, SPI, and I2C). A code-oriented, detailed analysis of the most common bus communication protocols is introduced by explaining the code required to interact with the transceivers commonly available in embedded systems.

Chapter 8, Power Management and Energy Saving, explores the techniques available to reduce power consumption in energy-efficient systems. Designing low-power and ultra-low-power embedded systems requires specific steps to be performed for reducing energy consumption while running the required tasks.

Chapter 9, Distributed Systems and IoT Architecture, introduces the available protocols and interfaces required to build distributed and connected systems. IoT systems need to communicate with remote endpoints using standard network protocols that are implemented using third-party libraries. Particular attention is dedicated to securing communication between endpoints using secure sockets.

Chapter 10, Parallel Tasks and Scheduling, explains the infrastructure of a multitasking operating system through the implementation of a real-time task scheduler. This chapter proposes three approaches for implementing operating systems for microcontrollers from scratch, using different schedulers (cooperative, pre-emptive, and safe).

Chapter 11, Trusted Execution Environment, describes the TEE mechanisms typically available on embedded systems and provides an example of running secure and non-secure domains using ARM TrustZone-M. On modern microcontrollers, TEE provides the opportunity to secure specific areas of memory or peripherals by limiting their access from the non-secure execution domain.

To get the most out of this book

It is expected that you are proficient in the C language and understand how computer systems work. A GNU or Linux development machine is required to apply the concepts explained. Going through the example code provided is sometimes necessary to fully understand the mechanisms implemented. You are encouraged to modify, improve, and reuse the examples provided, applying the suggested methodologies.

Additional usage instructions for the requested tools are available in Chapter 2, Work Environment and Workflow Optimization.

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book’s GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Embedded-Systems-Architecture-Second-Edition. If there’s an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://packt.link/kVMr1.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “A single configuration file must be provided from the command-line invocation, with several platforms and development board configurations provided under the /scripts directory.”

A block of code is set as follows:

  /* Jump to non secure app_entry */  asm volatile("mov r12, %0" ::"r"     ((uint32_t)app_entry - 1));  asm volatile("blxns   r12" );

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

   Secure Area 1:
     SECWM1_PSTRT : 0x0  (0x8000000)
     SECWM1_PEND  : 0x39  (0x8039000)

Any command-line input or output is written as follows:

$ renode /opt/renode/scripts/single-node/stm32f4_discovery.resc

Commands for the debugger console are written as follows:

    > add-symbol-file app.elf 0x1000
    > bt full

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at customercare@packtpub.com and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at copyright@packt.com with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share your thoughts

Once you’ve read Embedded Systems Architecture, Second Edition, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily!

Follow these simple steps to get the benefits:

1. Scan the QR code or visit the link below:

https://packt.link/free-ebook/9781803239545

2. Submit your proof of purchase
3. That’s it! We’ll send your free PDF and other benefits to your email directly

1

Embedded Systems – A Pragmatic Approach

Designing and writing software for embedded systems poses a different set of challenges than traditional high-level software development.

This chapter provides an overview of these challenges and introduces the basic components and the platform that will be used as a reference in this book.

In this chapter, we will discuss the following topics:

• Domain definition
• General-purpose input/output (GPIO)
• Interfaces and peripherals
• Connected systems
• Introduction to isolation mechanisms
• The reference platform

Domain definition

Embedded systems are computing devices that perform specific, dedicated tasks with no direct or continued user interaction. Due to the variety of markets and technologies, these objects have different shapes and sizes, but often, all have a small size and a limited amount of resources.

In this book, the concepts and the building blocks of embedded systems will be analyzed through the development of the software components that interact with their resources and peripherals. The first step is to define the scope for the validity of the techniques and the architectural patterns explained in this book, within the broader definition of embedded systems.

Embedded Linux systems

One part of the embedded market relies on devices with enough power and resources to run a variant of the GNU/Linux OS. These systems, often referred to as embedded Linux, are outside the scope of this book, as their development includes different strategies of design and integration of the components. A typical hardware platform that is capable of running a system based on the Linux kernel is equipped with a reasonably large amount of RAM, up to a few gigabytes, and sufficient storage space on board to store all the software components provided in the GNU/Linux distribution.

Additionally, for the Linux memory management to provide separate virtual address spaces to each process on the system, the hardware must be equipped with a memory management unit (MMU), a hardware component that assists the OS in translating physical addresses into virtual addresses, and vice versa, at runtime.

This class of devices presents different characteristics that are often overkill for building tailored solutions, which can use a much simpler design and reduce the production costs of single units.

Hardware manufacturers and chip designers have researched new techniques to improve the performance of microcontroller-based systems. In the past few decades, they have introduced new generations of platforms that would cut hardware costs, firmware complexity, size, and power consumption to provide a set of features that are most interesting for the embedded market.

Due to their specifications, in some real-life scenarios, embedded systems must be able to execute a series of tasks within a short, measurable, and predictable amount of time. These kinds of systems are called real-time systems and differ from the approach of multi-task computing, which is used in desktops, servers, and mobile phones.

Real-time processing is a goal that is extremely hard, if not impossible, to reach on embedded Linux platforms. The Linux kernel is not designed for hard real-time processing, and even if patches are available to modify the kernel scheduler to help meet these requirements, the results are not comparable to bare-metal, constrained systems that are designed with this purpose in mind.

Some other application domains, such as battery-powered and energy-harvesting devices, can benefit from the low power consumption capabilities of smaller embedded devices and the energy efficiency of the wireless communication technologies often integrated into embedded connected devices. The higher amount of resources and the increased hardware complexity of Linux-based systems often do not scale down enough on energy levels or require effort to meet similar figures in power consumption.

The type of microcontroller-based systems that we will analyze in this book is 32-bit systems, which are capable of running software in a single-threaded, bare-metal application, as well as integrating minimalist real-time OSs, which are very popular in the industrial manufacturing of embedded systems, which we use daily to accomplish specific tasks. They are becoming more and more adopted to help define more generic, multiple-purpose development platforms.

Low-end 8-bit microcontrollers

In the past, 8-bit microcontrollers dominated the embedded market. The simplicity of their design allows us to write small applications that can accomplish a set of predefined tasks but are too simple and usually equipped with too few resources to implement an embedded system, especially since 32-bit microcontrollers have evolved to cover all the use cases for these devices within the same range of price, size, and power consumption.

Nowadays, 8-bit microcontrollers are mostly relegated to the market of educational platform kits, aimed at introducing hobbyists and newcomers to the basics of software development on electronic devices. 8-bit platforms are not covered in this book because they lack the characteristics that allow advanced system programming, multithreading, and advanced features to be developed to build professional embedded systems.

In the context of this book, the term embedded systems is used to indicate a class of systems running on microcontroller-based hardware architecture, offering constrained resources but allowing real-time systems to be built through features provided by the hardware architecture to implement system programming.

Hardware architecture

The architecture of an embedded system is centered around its microcontroller, also sometimes referred to as the microcontroller unit (MCU). This is typically a single integrated circuit containing the processor, RAM, flash memory, serial receivers and transmitters, and other core components. The market offers many different choices among architectures, vendors, price ranges, features, and integrated resources. These are typically designed to be inexpensive, low-resource, low-energy consuming, self-contained systems on a single integrated circuit, which is the reason why they are often referred to as System-on-Chip (SoC).

Due to the variety of processors, memories, and interfaces that can be integrated, there is no actual reference architecture for microcontrollers. Nevertheless, some architectural elements are common across a wide range of models and brands, and even across different processor architectures.

Some microcontrollers are dedicated to specific applications and expose a particular set of interfaces to communicate to peripherals and the outside world. Others are focused on providing solutions with reduced hardware costs, or with very limited energy consumption.

Nevertheless, the following set of components is hardcoded into almost every microcontroller:

• Microprocessor
• RAM
• Flash memory
• Serial transceivers

Additionally, more and more devices are capable of accessing a network, to communicate with other devices and gateways. Some microcontrollers may provide either well-established standards, such as Ethernet or Wi-Fi interfaces, or specific protocols specifically designed to meet the constraints of embedded systems, such as sub-GHz radio interfaces or a Controller Area Network (CAN) bus, being partially or fully implemented within the IC.

All the components must share a bus line with the processor, which is responsible for coordinating the logic. The RAM, flash memory, and control registers of the transceivers are all mapped in the same physical address space:

Figure 1.1 – A simplified block diagram of the components inside a generic microcontroller

The addresses where RAM and Flash Memory are mapped depend on the specific model and are usually provided in the datasheet. A microcontroller can run code in its native machine language; that is, a sequence of instructions conveyed into a binary file that is specific to the architecture it is running on. By default, compilers provide a generic executable file as the output of the compilation and assembly operations, which needs to be converted into a format that can be executed by the target.

The Processor part is designed to execute the instructions that have been stored in its own specific binary format directly from RAM as well as from its internal flash memory. This is usually mapped starting from position zero in memory or another well-known address specified in the microcontroller manual. The CPU can fetch and execute code from RAM faster, but the final firmware is stored in the flash memory, which is usually bigger than the RAM on almost all microcontrollers and permits it to retain the data across power cycles and reboots.

Compiling a software operating environment for an embedded microcontroller and loading it onto the flash memory requires a host machine, which is a specific set of hardware and software tools. Some knowledge about the target device’s characteristics is also needed to instruct the compiler to organize the symbols within the executable image. For many valid reasons, C is the most popular language in embedded software, although not the only available option. Higher-level languages, such as Rust and C++, can produce embedded code when combined with a specific embedded runtime, or even in some cases by entirely removing the runtime support from the language.

Note

This book will focus entirely on C code because it abstracts less than any other high-level language, thus making it easier to describe the behavior of the underlying hardware while looking at the code.

All modern embedded systems platforms also have at least one mechanism (such as JTAG) for debugging purposes and uploading the software to the flash. When the debugging interface is accessed from the host machine, a debugger can interact with the breakpoint unit in the processor, interrupting and resuming the execution, and can also read and write from any address in memory.

A significant part of embedded programming is communicating the peripherals while using the interfaces that the MCU exposes. Embedded software development requires basic knowledge of electronics, the ability to understand schematics and datasheets, and confidence with the measurement tools, such as logic analyzers or oscilloscopes.

Understanding the challenges

Approaching embedded development means keeping the focus on the specifications as well as the hardware restrictions at all times. Embedded software development is a constant challenge that requires focusing on the most efficient way to perform a set of specific tasks but keeping the limited resources available in strong consideration. There are several compromises to deal with, which are uncommon in other environments. Here are some examples:

• There might be not enough space in the flash to implement a new feature
• There might not be enough RAM to store complex structures or make copies of large data buffers
• The processor might be not fast enough to accomplish all the required calculations and data processing in due time
• Battery-powered and resource-harvesting devices might require lower energy consumption to meet lifetime expectations

Moreover, PC and mobile OSs make large use of the MMU, a component of the processor that allows runtime translations between physical and virtual addresses.

The MMU is a necessary abstraction to implement address space separation among the tasks, as well as between the tasks and the kernel itself. Embedded microcontrollers do not have an MMU, and usually lack the amount of non-volatile memory required to store kernels, applications, and libraries. For this reason, embedded systems are often running in a single task, with the main loop performing all the data processing and communication in a specific order. Some devices can run embedded OSs, which are far less complex than their PC counterparts.

Application developers often see the underlying system as a commodity, while embedded development often means that the entire system has to be implemented from scratch, from the boot procedure up to the application logic. In an embedded environment, the various software components are more closely related to each other because of the lack of more complex abstractions, such as memory separations between the processes and the OS kernel.

A developer approaching embedded systems for the first time might find testing and debugging on some of the systems a bit more intricate than just running the software and reading out the results. This becomes especially true in those systems that have been designed with little or no human interaction interfaces.

A successful approach requires a healthy workflow, which includes well-defined test cases, a list of key performance indicators coming from the analysis of the specifications to identify possibilities of trade-offs, several tools and procedures at hand to perform all the needed measurements, and a well-established and efficient prototyping phase.

In this context, security deserves some special consideration. As usual, when writing code at the system level, it is wise to keep in mind the system-wide consequences of possible faults. Most embedded application code runs with extended privileges on the hardware, and a single task misbehaving can affect the stability and integrity of the entire firmware. As we will see, some platforms offer specific memory protection mechanisms and built-in privilege separation, which are useful for building fail-safe systems, even in the absence of a full OS based on separating process address spaces.

Multithreading

One of the advantages of using microcontrollers designed to build embedded systems is the possibility to run logically separated tasks within separate execution units by time-sharing the resources.

The most popular type of design for embedded software is based on a single loop-based sequential execution model, where modules and components are connected to expose callback interfaces. However, modern microcontrollers offer features and core logic characteristics that can be used by system developers to build a multitasking environment to run logically separated applications.

These features are particularly handy in the approach to more complex real-time systems, and they help us understand the possibilities of the implementation of safety models based on process isolation and memory segmentation.

RAM

“640 KB of memory ought to be enough for everyone”

– Bill Gates (founder and former director of Microsoft)

This famous statement has been cited many times in the past three decades to underline the progress in technology and the outstanding achievements of the PC industry. While it may sound like a joke for many software engineers out there, it is still in these figures that embedded programming has to be thought about, more than 30 years after MS-DOS was initially released.

Although most embedded systems are capable of breaking that limit today, especially due to the availability of external DRAM interfaces, the simplest devices that can be programmed in C may have as little as 4 KB of RAM available to implement the entire system logic. This has to be taken into account when designing an embedded system, by estimating the amount of memory potentially needed for all the operations that the system has to perform, and the buffers that may be used at any time to communicate with peripherals and nearby devices.

The memory model at the system level is simpler than that of PCs and mobile devices. Memory access is typically done at the physical level, so all the pointers in your code are telling you the physical location of the data they are pointing to. In modern computers, the OS is responsible for translating physical addresses into a virtual representation of the running tasks.

The advantage of the physical-only memory access on those systems that do not have an MMU is the reduced complexity of having to deal with address translations while coding and debugging. On the other hand, some of the features that are implemented by any modern OS, such as process swapping and dynamically resizing address spaces through memory relocation, become cumbersome and sometimes impossible.

Handling memory is particularly important in embedded systems. Programmers who are used to writing application code expect a certain level of protection to be provided by the underlying OS. A virtual address space does not allow memory areas to overlap, and the OS can easily detect unauthorized memory accesses and segmentation violations, so it promptly terminates the process and avoids having the whole system compromised.

On embedded systems, especially when writing bare-metal code, the boundaries of each address pool must be checked manually. Accidentally modifying a few bits in the wrong memory, or even accessing a different area of memory, may result in a fatal, irrevocable error. The entire system may hang, or, in the worst case, become unpredictable. A safe approach is required when handling memory in embedded systems, in particular when dealing with life-critical devices. Identifying memory errors too late in the development process is complex and often requires more resources than forcing yourself to write safe code and protecting the system from a programmer’s mistakes.

Proper memory-handling techniques will be explained in Chapter 5, Memory Management.

Flash memory

In a server or a personal computer, the executable applications and libraries reside in storage devices. At the beginning of the execution, they are accessed, transformed, possibly uncompressed, and stored in RAM before the execution starts.

The firmware of an embedded device is, in general, one single binary file containing all the software components, which can be transferred to the internal flash memory of the MCU. Since the flash memory is directly mapped to a fixed address in the memory space, the processor is capable of sequentially fetching and executing single instructions from it with no intermediate steps. This mechanism is called execute in place (XIP).

All non-modifiable sections on the firmware do not need to be loaded in memory and are accessible through direct addressing in the memory space. This includes not only the executable instructions but also all the variables that are marked as constant by the compiler. On the other hand, supporting XIP requires a few extra steps when preparing the firmware image to be stored in flash, and the linker needs to be instructed about the different memory-mapped areas on the target.

The internal flash memory that is mapped in the address space of the microcontroller is not accessible for writing. Altering the content of the internal flash can be done only by using block-based access, due to the hardware characteristics of flash memory devices. Before changing the value of a single byte in flash memory, the whole block containing it must be erased and rewritten. The mechanism offered by most manufacturers to access block-based flash memory for writing is known as In-Application Programming (IAP). Some filesystem implementations take care of abstracting write operations on a block-based flash device, by creating a temporary copy of the block where the write operation is performed.

While selecting the components for a microcontroller-based solution, it is vital to match the size of the flash memory to the space required by the firmware. The flash is often one of the most expensive components in the MCU, so for deployment on a large scale, choosing an MCU with a smaller flash could be more cost-effective. Developing software with code size in mind is not very usual nowadays within other domains, but it may be required when trying to fit multiple features in such little storage. Finally, compiler optimizations may exist on specific architectures to reduce code size when building the firmware and linking its components.

Additional non-volatile memories that reside outside of the MCU silicon can typically be accessed using specific interfaces, such as the Serial Peripheral Interface. External flash memories use different technologies than internal flash, which is designed to be fast and execute code in place. While being generally more dense and less expensive, external flash memories do not allow direct memory mapping in the physical address space, which makes them unsuitable for storing firmware images. This is because it would be impossible to execute the code fetching the instructions sequentially unless a mechanism is used to load the executable symbols in RAM – read access on these kinds of devices is performed one block at a time. On the other hand, write access may be faster compared to IAP, making these kinds of non-volatile memory devices ideal for storing data that is retrieved at runtime in some designs.

General-purpose input/output (GPIO)

The most basic functionality that can be achieved with any microcontroller is the possibility to control signals on specific pins of the integrated circuit. The microcontroller can turn a digital output on or off, which corresponds to a reference voltage to be applied to the pin when the value assigned to it is 1, and zero volts when the value is 0. In the same way, a pin can be used to detect a 1 or a 0 when the pin is configured as input. The software will read the digital value “1” when the voltage applied to it is higher than a certain threshold.

ADC and DAC

Some chips have onboard ADC controllers, which are capable of sensing the voltage that is applied to the pin and sampling it. This is often used to acquire measurements from input peripherals providing a variable voltage as output. The embedded software will be able to read the voltage, with an accuracy that depends on the predefined range.

A DAC controller is the inverse of an ADC controller, transforming a value on a microcontroller register into the corresponding voltage.

Timers and PWM

Microcontrollers may offer diverse ways to measure time. Often, there is at least one interface based on a countdown timer that can trigger an interrupt and automatically reset upon expiry.

GPIO pins configured as output can be programmed to output a square wave with a preconfigured frequency and duty cycle. This is called pulse-wave modulation (PWM) and has several uses, from controlling output peripherals to dimming an LED or even playing an audible sound through a speaker.

More details about GPIO, interrupt timers, and watchdogs will be explored in Chapter 6, General-Purpose Peripherals.

Interfaces and peripherals

To communicate with peripherals and other microcontrollers, several de facto standards are well established in the embedded world. Some of the external pins of the microcontroller can be programmed to carry out communication with external peripherals using specific protocols. A few of the common interfaces available on most architectures are as follows:

• Asynchronous UART-based serial communication
• Serial Peripheral Interface (SPI) bus
• Inter-integrated circuit (I2C) bus
• Universal Serial Bus (USB)

Let’s review each in detail.

Asynchronous UART-based serial communication

Asynchronous communication is provided by the Universal Asynchronous Receiver-Transmitter (UART). These kinds of interfaces, commonly known as serial ports, are called asynchronous because they do not need to share a clock signal to synchronize the sender and the receiver, but rather work on predefined clock rates that can be aligned while the communication is ongoing. Microcontrollers may contain multiple UARTs that can be attached to a specific set of pins upon request. Asynchronous communication is provided by UART as a full-duplex channel, through two independent wires, connecting the RX pin of each endpoint to the TX pin on the opposite side.

To understand each other, the systems at the two endpoints must set up the UART using the same parameters. This includes the framing of the bytes on the wire and the frame rate. All of these parameters have to be known in advance by both endpoints to correctly establish a communication channel. Despite being simpler than the other types of serial communication, UART-based serial communication is still widely used in electronic devices, particularly as an interface for modems and GPS receivers. Furthermore, using TTL-to-USB serial converters, it is easy to connect a UART to a console on the host machine, which is often handy for providing log messages.

SPI

A different approach to classic UAR—based communication is SPI. Introduced in the late 1980s, this technology aimed to replace asynchronous serial communication toward peripherals by introducing several improvements:

• Serial clock line to synchronize the endpoints
• Master-slave protocol
• One-to-many communication over the same three-wire bus

The master device, usually the microcontroller, shares the bus with one or more slaves. To trigger the communication, a separate slave select (SS) signal is used to address each slave connected to the bus. The bus uses two independent signals for data transfer, one per direction, and a shared clock line that synchronizes the two ends of the communication. Due to the clock line being generated by the master, the data transfer is more reliable, making it possible to achieve higher bitrates than ordinary UART. One of the keys to the continued success of SPI over multiple generations of microcontrollers is the low complexity required for the design of slaves, which can be as simple as a single shift register. SPI is commonly used in sensor devices, LCDs, flash memory controllers, and network interfaces.

I2C

I2C is slightly more complex, and that is because it is designed with a different purpose in mind: interconnecting multiple microcontrollers, as well as multiple slave devices, on the same two-wire bus. The two signals are serial clock (SCL) and serial data (SDA). Unlike SPI or UART, the bus is half-duplex, as the two directions of the flow share the same signal. Thanks to a 7-bit slave-addressing mechanism incorporated in the protocol, it does not require additional signals dedicated to selecting the slaves. Multiple masters are allowed on the same line, given that all the masters in the system follow the arbitration logic in the case of bus contention.

USB

The USB protocol, originally designed to replace UART and include many protocols in the same hardware connector, is very popular in personal computers, portable devices, and a huge number of peripherals.

This protocol works in host-device mode, with one side of communication, the device, exposing services that can be used by the controller, on the host side. USB transceivers present in many microcontrollers can work in both modes. By implementing the upper layer of the USB standards, different types of devices can be emulated by the microcontroller, such as serial ports, storage devices, and point-to-point Ethernet interfaces, creating microcontroller-based USB devices that can be connected to a host system.

If the transceiver supports host mode, the embedded system can act as a USB host, and devices can be connected to it. In this case, the system should implement device drivers and applications to access the functionality provided by the device.

When both modes are implemented on the same USB controller, the transceiver works in on-the-go (OTG) mode, and selecting and configuring the desired mode can be done at runtime.

A more extended introduction to some of the most common protocols used for communicating with peripherals and neighboring systems will be provided in Chapter 7, Local Bus Interfaces.

Connected systems

An increasing number of embedded devices designed for different markets are now capable of network communication with their peers in the surrounding area or with gateways routing their traffic to a broader network or the internet. The term Internet of Things (IoT) has been used to describe the networks where those embedded devices can communicate using internet protocols.

This means that IoT devices can be addressed within the network in the same way as more complex systems, such as PCs or mobile devices, and most importantly, they use the transport layer protocols typical of internet communications to exchange data. TCP/IP is a suite of protocols standardized by the IETF, and it is the fabric of the infrastructure for the internet and other self-contained, local area networks.

The Internet Protocol (IP) provides network connectivity, but on the condition that the underlying link provides packet-based communication and mechanisms to control and regulate access to the physical media. Fortunately, many network interfaces meet these requirements. Alternative protocol families, which are not compatible with TCP/IP, are still in use in several distributed embedded systems, but a clear advantage of using the TCP/IP standard on the target is that, in the case of communication with non-embedded systems, there is no need for a translation mechanism to route the frames outside the scope of the LAN.

Besides the types of links that are widely used in non-embedded systems, such as Ethernet or wireless LAN, embedded systems can benefit from a wide choice of technologies that are specifically designed for the requirements introduced by IoT. New standards have been researched and put into effect to provide efficient communication for constrained devices, defining communication models to cope with specific resource usage limits and energy efficiency requirements.

Recently, new link technologies have been developed in the direction of lower bitrates and power consumption for wide-area network communication. These protocols are designed to provide narrow-band, long-range communication. The frame is too small to fit IP packets, so these technologies are mostly employed to transmit small payloads, such as periodic sensor data, or device configuration parameters if a bidirectional channel is available, and they require some form of gateway to translate the communication so that it can travel across the internet.

The interaction with the cloud services, however, requires, in most cases, connecting all the nodes in the network, and implementing the same technologies used by the servers and the IT infrastructure directly in the host. Enabling TCP/IP communication on an embedded device is not always straightforward. Even though there are several open source implementations available, system TCP/IP code is complex, big in size, and often has memory requirements that may be difficult to meet.

The same observation applies to the Secure Socket Layer (SSL)/Transport Layer Security (TLS) library, which adds confidentiality and authentication between the two communication endpoints. Choosing the right microcontroller for the task is, again, crucial, and if the system has to be connected to the internet and support secure socket communication, then the flash and RAM requirements have to be updated in the design phase to ensure integration with third-party libraries.

Challenges of distributed systems

Designing distributed embedded systems, especially those that are based on wireless link technologies, adds a set of interesting challenges.

Some of these challenges are related to the following aspects:

• Selecting the correct technologies and protocols
• Limitations on bitrate, packet size, and media access
• Availability of the nodes
• Single points of failure in the topology
• Configuring the routes
• Authenticating the hosts involved
• The confidentiality of the communication over the media
• The impact of buffering on network speed, latency, and RAM usage
• The complexity of implementing the protocol stacks

Chapter 9, Distributed Systems and IoT Architecture, analyzes some of the link-layer technologies implemented in embedded systems to provide remote communication, where TCP/IP communication is integrated into the design of distributed systems that are integrated with IoT services.

Introduction to isolation mechanisms

Some newer microcontrollers include support for isolation between trusted and non-trusted software running onboard. This mechanism is based on a CPU extension, available only on some specific architectures, which usually relies on a sort of physical separation inside the CPU itself between the two modes of execution. All the code running from a non-trusted zone in the system will have a restricted view of the RAM, devices, and peripherals, which must be dynamically configured by the trusted counterpart in advance.

Software running from the trusted area can also provide features that are not directly accessible from the non-trusted world, through special function calls that cross the secure/non-secure boundary.

Chapter 11, Trusted Execution Environment, explores the technology behind Trust Execution Environments (TEEs), as well as the software components involved in real embedded systems to provide a safe environment to run non-trusted modules and components.

The reference platform

The preferred design strategy for embedded CPU cores is reduced instruction set computer (RISC). Among all the RISC CPU architectures, several reference designs are used as guidelines by silicon manufacturers to produce the core logic to integrate into the microcontroller. Each reference design differs from the others in several characteristics of the CPU implementation. Each reference design includes one or more families of microprocessors integrated into embedded systems, which share the following characteristics:

• Word size used for registers and addresses (8-bit, 16-bit, 32-bit, or 64-bit)
• Instruction set
• Register configurations
• Endianness
• Extended CPU features (interrupt controller, FPU, MMU)
• Caching strategies
• Pipeline design

Choosing a reference platform for your embedded system depends on your project needs. Smaller, less feature-rich processors are generally more suited to low energy consumption, have a smaller MCU packaging, and are less expensive. Higher-end systems, on the other hand, come with a bigger set of resources and some of them have dedicated hardware to cope with challenging calculations (such as a floating-point unit, or an Advanced Encryption Standard (AES) hardware module to offload symmetric encryption operations). 8-bit and 16-bit core designs are slowly giving way to 32-bit architectures, but some successful designs remain relatively popular in some niche markets and among hobbyists.

ARM reference design

ARM is the most ubiquitous reference design supplier in the embedded market, with more than 10 billion ARM-based microcontrollers produced for embedded applications. One of the most interesting core designs in the embedded industry is the ARM Cortex-M family, which includes a range of models scaling from cost-effective and energy-efficient, to high-performance cores specifically designed for multimedia microcontrollers. Despite ranging among three different instruction sets (ARMv6, ARMv7, and ARMv8), all Cortex-M CPUs share the same programming interface, which improves portability across microcontrollers in the same families.

Most of the examples in this book will be based on this family of CPUs. Though most of the concepts expressed will apply to other core designs as well, picking a reference platform now opens the door to a more complete analysis of the interactions with the underlying hardware. In particular, some of the examples in this book use specific assembly instructions from the ARMv7 instruction set, which is implemented in some Cortex-M CPU cores.

The Cortex-M microprocessor

The main characteristic of the 32-bit cores in the Cortex-M family are as follows:

• 16 generic-purpose CPU registers
• Thumb 16-bit only instructions for code density optimizations
• A built-in Nested Vector Interrupt Controller (NVIC) with 8 to 16 priority levels
• ARMv6-M (M0, M0+), ARMv7-M (M3, M4, M7), or ARMv8-M (M23, M33) architecture
• Optional 8-region memory protection unit (MPU)
• Optional TEE isolation mechanism (ARM TrustZone-M)

The total memory address space is 4 GB. The beginning of the internal RAM is typically mapped at the fixed address of 0x20000000. The mapping of the internal flash, as well as the other peripherals, depends on the silicon manufacturer. However, the highest 512 MB (0xE0000000 to 0xFFFFFFFF) addresses are reserved for the System Control Block (SCB), which groups together several configuration parameters and diagnostics that can be accessed by the software at any time to directly interact with the core.

Synchronous communication with peripherals and other hardware components can be triggered through interrupt lines. The processor can receive and recognize several different digital input signals and react to them promptly, interrupting the execution of the software and temporarily jumping to a specific location in the memory. Cortex-M supports up to 240 interrupt lines on the high-end cores of the family.

The interrupt vector, located at the beginning of the software image in flash, contains the addresses of the interrupt routines that will automatically execute on specific events. Thanks to the NVIC, interrupt lines can be assigned priorities so that when a higher-priority interrupt occurs while the routine for a lower interrupt is executed, the current interrupt routine is temporarily suspended to allow the higher-priority interrupt line to be serviced. This ensures minimal interrupt latency for these signal lines, which are somewhat critical for the system to execute as fast as possible.

At any time, the software on the target can run in two privilege modes: unprivileged or privileged. The CPU has built-in support for privilege separation between system and application software, even providing two different registers for the two separate stack pointers. In Chapter 10, Parallel Tasks and Scheduling, we will examine how to properly implement privilege separation, as well as how to enforce memory separation when running untrusted code on the target, in more detail. This is, for example, used to hide secrets such as private keys from direct access from the non-secure world. In Chapter 11, Trusted Execution Environment, we will learn how to properly implement privilege separation, as well as how to enforce memory separation within an OS when running application code on the target with a different level of trust.

A Cortex-M core is present in many microcontrollers, from different silicon vendors. Software tools are similar for all the platforms, but each MCU has a different configuration to take into account. Convergence libraries are available to hide manufacturer-specific details and improve portability across different models and brands. Manufacturers provide reference kits and all the documentation required to get started, which are intended to be used for evaluation during the design phase, and may also be useful for developing prototypes at a later stage. Some of these evaluation boards are equipped with sensors, multimedia electronics, or other peripherals that extend the functionality of the microcontroller. Some even include preconfigured, third-party “middleware” libraries such as TCP/IP communication stacks, TLS and cryptography libraries, simple filesystems and other accessory components, and modules that can be quickly and easily added to a software project.

Summary

When approaching embedded software requirements, before anything else, you must have a good understanding of the hardware platform and its components. By describing the architecture of modern microcontrollers, this chapter pointed out some of the peculiarities of embedded devices and how developers should efficiently rethink their approach to meeting requirements and solving problems, while at the same time taking into account the features and the limits of the target platform.

In the next chapter, we will analyze the tools and procedures typically used in embedded development, including command-line toolchains and integrated development environments (IDEs). We will understand how to organize the workflow and how to effectively prevent, locate, and fix bugs.

2

Work Environment and Workflow Optimization

The first step toward a successful software project is choosing the right tools. Embedded development requires a set of hardware and software instruments that make the developer’s life easier and may significantly improve productivity and cut down the total development time. This chapter provides a description of these tools and gives advice on how to use them to improve the workflow.

The first section gives us an overview of the workflow in native C programming, and gradually reveals the changes necessary to translate the model to an embedded development environment. The GCC toolchain, a set of development tools to build the embedded application, is introduced through the analysis of its components.

Finally, in the last two sections, strategies of interaction with the target are proposed, to provide mechanisms for the debugging and validation of the embedded software running on the platform.

The topics covered in this chapter are the following:

• Workflow overview
• Text editors versus integrated environments
• The GCC toolchain
• Interaction with the target
• Validation

By the end of this chapter, you will have learned how to create an optimized workflow by following a few basic rules, keeping the focus on test preparation, and a smart approach to debugging.

Workflow overview

Writing software in C, as well as in every other compiled language, requires the code to be transformed into an executable format for a specific target to run it. C is portable across different architectures and execution environments. Programmers rely on a set of tools to compile, link, execute, and debug software to a specific target.

Building the firmware image of an embedded system relies on a similar set of tools, which can produce firmware images for specific targets, called a toolchain. This section gives an overview of the common sets of tools required to write software in C and produce programs that are directly executable on the machine that compiled them. The workflow must then be extended and adapted to integrate the toolchain components and produce executable code for the target platform.

The C compiler

The C compiler is a tool responsible for translating source code into machine code, which can be interpreted by a specific CPU. Each compiler can produce machine code for one environment only, as it translates the functions into machine-specific instructions, and it is configured to use the address model and the register layout of one specific architecture. The native compiler included in most GNU/Linux distributions is the GNU Compiler Collection, commonly known as GCC. The GCC is a free software compiler system distributed under the GNU general public license since 1987, and since then, it has been successfully used to build UNIX-like systems. The GCC included in the system can compile C code into applications and libraries capable of running on the same architecture as that of the machine running the compiler.

The GCC compiler takes source code files as input, with the .c extension, and produces object files, with .o extensions, containing the functions and the initial values of the variables, translated from the input source code into machine instructions. The compiler can be configured to perform additional optimization steps at the end of the compilation that are specific to the target platform and insert debug data to facilitate debugging at a later stage.

A minimalist command line used to compile a source file into an object using the host compiler only requires the -c option, instructing the GCC program to compile the sources into an object of the same name:

$ gcc -c hello.c

This statement will try to compile the C source contained in the hello.c file and transform it into machine-specific code that is stored in the newly created hello.o file.

Compiling code for a specific target platform requires a set of tools designed for that purpose. Architecture-specific compilers exist, which provide compilers creating machine instructions for a specific target, different from the building machine. The process of generating code for a different target is called cross compilation. The cross compiler runs on a development machine, the host, to produce machine-specific code that can execute on the target.

In the next section, a GCC-based toolchain is introduced as the tool to create the firmware for an embedded target. The syntax and the characteristics of the GCC compiler are described there.

The first step for building a program made of separate modules is to compile all the sources into object files so that the components needed by the system are grouped and organized together in the final step, consisting of linking together all the required symbols and arranging the memory areas to prepare the final executable, which is done by another dedicated component in the toolchain.

Linker

The linker is the tool that composes executable programs and resolves the dependencies among object files provided as input.

The default executable format that is produced by the linker is the Executable and Linkable Format (ELF). The ELF is the default standard format for programs, objects, shared libraries, and even GDB core dumps on many Unix and Unix-like systems. The format has been designed to store programs on disks and other media supports, so the host operating system can execute it by loading the instructions in RAM and allocating the space for the program data.

Executable files are divided into sections, which can be mapped to specific areas in memory needed by the program to execute. The ELF file starts with a header containing the pointer to the various sections within the file itself, which contains the program’s code and data.

The linker maps the content of the areas describing an executable program into sections conventionally starting with a . (dot). The minimum set of sections required to run the executable consists of the following:

• .text: Contains the code of the program, accessed in read-only mode. It contains the executable instructions of the program. The functions compiled into object files are arranged by the linker in this section, and the program always executes instructions within this memory area.
• .rodata: Contains the value of constants that cannot be altered at runtime. It is used by the compiler as the default section to store constants because it is not allowed to modify the stored values at runtime.
• .data: Contains the values of all the initialized variables of the program that are accessible in the read/write mode at runtime. It is the section that contains all the variables (static or global) that have been initialized in the code. Before executing, this area is generally remapped to a writable location in RAM, and the content of the ELF is automatically copied during the initialization of the program, at runtime, before executing the main function.
• .bss: This is a section reserved for uninitialized data, accessible in the read/write mode at runtime. It derives its name from an ancient assembly instruction of old microcode written for the IBM 704 in the 1950s. It was originally an acronym for Block Started by Symbol (BSS), used to reserve a fixed amount of uninitialized memory. In the ELF context, it contains all the uninitialized global and static symbols, which must be accessible in the read-write mode at runtime. Because there is no value assigned, the ELF file only describes the section in the header but does not provide any content for it. The initialization code should ensure that all the variables in this section are set to zero before the execution of the main() function.

When building native software on the host machine, much of the complexity of the linking step is hidden, but the linker is configured by default to arrange the compiled symbols into specific sections, which can be later used by the operating system to assign the corresponding segments in the process virtual address space when executing the program. It is possible to create a working executable for the host machine by simply invoking gcc, this time without the -c option, providing the list of the object files that must be linked together to produce the ELF file. The -o option is used to specify the output filename, which otherwise would default to a.out:

$ gcc -o helloworld hello.o world.o

This command will try to build the helloworld file, which is an ELF executable for the host system, using the symbols previously compiled into the two objects.

In an embedded system things change a bit, as booting a bare-metal application implies that the sections must be mapped to physical areas in memory at linking time. To instruct the linker to associate the sections to well-known physical addresses, a custom linker script file must be provided, describing the memory layout of the executable bare-metal application, and providing additional custom sections that may be required by the target system.

A more detailed explanation of the linking step is provided later, in the Linking the executable section.

Make: a build automation tool

Several open source tools are available to automate a build process, and a few of them are widely used in different development environments. Make is the standard UNIX tool to automate the steps required to create the required binary images from the sources, check the dependencies for each component, and execute the steps in the right order. Make is a standard POSIX tool, and it is part of many UNIX-like systems. In a GNU/Linux distribution, it is implemented as a standalone tool, which is part of the GNU project. From this point on, the GNU Make implementation is simply referred to as Make.

Make is designed to execute the default build by simply invoking the make command with no arguments from the command line, provided that a makefile is present in the working directory. A makefile is a special instruction file, containing rules and recipes to build all the files needed until the expected output files are generated. Open source alternatives offering similar solutions for build automation exist, such as CMake and SCons, but all the examples in this book are built using Make because it provides a simple and essential enough environment to control the build system, and it is the one standardized by POSIX.

Some integrated development environments use built-in mechanisms to coordinate the building steps or generate makefiles before invoking Make automatically when the user requests to build the output files. However, editing makefiles manually gives complete control over the intermediate steps to generate the final images, where the user can customize the recipes and rules used to generate the desired output files.

There is no specific version that needs to be installed to cross compile code for the Cortex-M target, but some extra parameters, such as the location of the toolchain binaries, or the specific flags needed by the compiler, need to be taken care of when writing targets and directives within the makefile.

One of the advantages of using a build process is that targets may have implicit dependencies from other intermediate components that are automatically resolved at compile time. If all the dependencies are correctly configured, a makefile ensures that the intermediate steps are executed only when needed, reducing the compile time of the whole project when only a few sources are altered or when single object files have been deleted.

Makefiles have a specific syntax to describe rules. Each rule begins with the target files expected as the output of the rule, a colon, and the list of prerequisites, which are the files necessary to execute the rule. A set of recipe items follow, each one describing the actions that Make will execute to create the desired target:

target: [prerequisites]
 recipe
 recipe
 ...

By default, Make will execute the first rule encountered while parsing the file if no rule name is specified from the command line. If any of the prerequisites are not available, Make automatically looks for a rule in the same makefile that can create the required file recursively until the chain of requirements is satisfied.

Makefiles can assign a custom string of text to internal variables while executing. Variable names can be assigned using the = operator and referred to by prefixing them with $. For example, the following assignment is used to put the name of two object files into the OBJS variable:

OBJS = hello.o world.o

A few important variables that are assigned automatically within the rules are the following:

Table 2.1 – Some automatic variables that can be used in makefile recipes

These variables are handy to use within the recipe action lines. For example, the recipe to generate a helloworld ELF file from the two object files can be written as follows:

helloworld: $(OBJS)
 gcc -o $(@) $(^)

Some of the rules are implicitly defined by Make. For example, the rule to create the hello.o and world.o files from their respective source files can be omitted, as Make expects to be able to obtain each one of these object files in the most obvious way, which is by compiling the corresponding C source files with the same name if present. This means that this minimalist makefile is already able to compile the two objects from the sources and link them together using the default set of options for the host system.

The linking recipe can also be implicit if the executable has the same name as one of its prerequisite objects minus its .o extension. If the final ELF file is called hello, our makefile could simply become the following one-liner:

hello: world.o

This would automatically resolve the hello.o and world.o dependencies, and then link them together using an implicit linker recipe similar to the one we used in the explicit target.

Implicit rules use predefined variables, which are assigned automatically before the rules are executed, but can be modified within the makefile. For example, it is possible to change the default compiler by altering the CC variable. Here is a short list of the most important variables that may be used to alter implicit rules and recipes:

Table 2.2 – Implicit, predefined variables that specify the default toolchain and flags

When linking a bare-metal application for embedded platforms, the makefile must be modified accordingly, and as shown later in this chapter, several flags are required to properly cross compile the sources and instruct the linker to use the desired memory layout to organize the memory sections. Moreover, additional steps are generally needed to manipulate the ELF file and translate it to a format that can be transferred to the target system. However, the syntax of the makefile is the same, and the simple rules shown here are not too different from those used to build the example. The default variables still need to be adjusted to modify the default behavior if implicit rules are used.

When all the dependencies are correctly configured in the makefile, Make ensures that the rules are only executed when the target is older than its dependencies, thus reducing the compile time of the whole project when only a few sources are altered or when single object files have been deleted.

Make is a very powerful tool, and its range of possibilities goes far beyond the few features used to generate the examples in this book. Mastering the automation process of builds may lead to optimized build processes. The syntax of makefiles includes useful features, such as conditionals, which can be used to produce different results by invoking a makefile using different targets or environment variables. For a better understanding of the capabilities of Make, please refer to the GNU Make manual available at https://www.gnu.org/software/make/manual.

Debugger

In the host environment, debugging an application that runs on top of the operating system is done by running a debugger tool, which can attach to an existing process or spawn a new one given an executable ELF file and its command-line arguments. The default debugging option provided by the GCC suite is called GDB, an acronym for the GNU Debugger. While GDB is a command-line tool, several frontends have been developed to provide better visualization of the state of the execution, and some integrated development environments provide built-in frontends for interacting with the debugger while tracing the single lines being executed.

Once again, the situation is slightly changed when the software to debug is running on a remote platform. A version of GDB, distributed with the toolchain and specific to the target platform, can be run on the development machine to connect to a remote debug session. A debug session on a remote target requires an intermediate tool that is configured to translate GDB commands into actual actions on the core CPU and the related hardware infrastructure to establish communication with the core.

Some embedded platforms provide hardware breakpoints, which are used to trigger system exceptions every time the selected instructions are executed.

Later in this chapter, we will see how a remote GDB session can be established with the target in order to interrupt its execution at the current point, proceed to step through the code, place breakpoints and watchpoints, and inspect and modify the values in memory.

A handful of GDB commands are introduced, giving a quick reference to some of the functionalities provided by the GDB command-line interface, which can be effectively used to debug embedded applications.

The debugger gives the best possible understanding of what the software is doing at runtime and facilitates the hunt for programming errors while directly looking at the effects of the execution on memory and CPU registers.

Embedded workflow

If compared to other domains, the embedded development life cycle includes some additional steps. The code must be cross compiled, the image manipulated then uploaded to a target, tests must be run, and possibly hardware tools are involved in the measurement and verification phases. The life cycle of native application software, when using compiled languages, looks like this diagram:

Figure 2.1 – A typical life cycle of application development

When writing software within the same architecture, tests and debugging can be performed right after compiling, and it is often easier to detect issues. This results in a shorter time for the typical loop. Moreover, if the application crashes because of a bug, the underlying operating system can produce a core dump, which can be analyzed using the debugger at a later time by restoring the content of the virtual memory and the context of the CPU registers right at the moment when the bug shows up.

On the other hand, intercepting fatal errors on an embedded target might be slightly more challenging because of the potential side effect of memory and register corruption in the absence of virtual addresses and memory segmentation provided by the operating systems in other contexts. Even if some targets can intercept abnormal situations by triggering diagnostic interrupts, such as the hard fault handler in Cortex-M, restoring the original context that generated the error is often impossible.

Furthermore, every time new software is generated, there are a few time-consuming steps to perform, such as the translation of the image to a specific format, and uploading the image to the target itself, which may take anywhere from a few seconds up to a minute, depending on the size of the image and the speed of the interface used to communicate with the target:

Figure 2.2 – The embedded development life cycle, including additional steps required by the environment

In some of the phases of the development, when multiple consecutive iterations may be required to finalize a feature implementation or detect a defect, the timing between compiling and testing the software has an impact on the efficiency of the whole life cycle. Specific tasks implemented in the software, which involve communication through serial or network interfaces, can only be verified with signal analysis or by observing the effect on the peripheral or the remote system involved. Analyzing the electrical effects on the embedded system requires some hardware setup and instrument configuration, which add more time to the equation.

Finally, developing a distributed embedded system composed of several devices running different software images may result in repeating the preceding iterations for each of these devices. Whenever possible, these steps should be eliminated by using the same image and different set configuration parameters on each device and by implementing parallel firmware upgrade mechanisms. Protocols such as JTAG support uploading the software image to multiple targets sharing the same bus, significantly cutting down the time required for the firmware upgrades, especially in those distributed systems with a larger number of devices involved.

No matter how complex the project is expected to be, it is, in general, worth spending as much time as needed to optimize the life cycle of the software development at the beginning in order to increase efficiency later on. No developer likes to switch the focus away from the actual coding steps for too long, and it might be frustrating to work in a suboptimal environment where stepping through the process requires too much time or human interaction.

An embedded project can be started from scratch using a text editor or by creating a new project in an integrated development environment.

Text editors versus integrated environments

While mostly a matter of developer preferences, the debate is still open in the embedded community between those who use a standalone text editor and those who prefer to have all the components of the toolchain integrated into one GUI.

Modern IDEs incorporate tools for the following tasks:

• Managing the components of the project
• Quickly accessing all the files for editing as well as extensions to upload the software on the board
• Starting a debugging session with a single click

Microcontroller manufacturers often distribute their development kits along with IDEs that make it easy to access advanced features that are specific to the microcontroller, thanks to preconfigured setups and wizards facilitating the creation of new projects. Most IDEs include widgets to automatically generate the setup code for pin multiplexing for specific microcontrollers, starting from a graphical interface. Some of them even offer simulators and tools to predict runtime resource usage, such as dynamic memory and power consumption.

The majority of these tools are based on some customization of Eclipse, a popular open source desktop IDE, originally designed as a tool for Java software development, then later on very successful in many other fields thanks to the possibilities to extend and customize its interface.

There are downsides to the IDE approach too. IDEs, in general, do not embed the actual toolchain in the code. Rather, they provide a frontend interface to interact with a compiler, linker, debugger, and other tools. To do so, they have to store all the flags, configuration options, the paths of included files, and compile-time-defined symbols in a machine-readable configuration file. Some users find those options difficult to access by navigating through the multiple menus of the GUI. Other key components of the project, such as the linker script, may also be well hidden under the hood, in some cases even automatically generated by the IDE and difficult to read. For most IDE users, however, these downsides are compensated by the perks of developing with an integrated environment.

There is one last caveat that has to be considered, though. The project will sooner or later be built and tested automatically, as previously analyzed in the Make: a build automation tool section. Robots are, in general, terrible users of IDEs, while they can build and run any test, even interacting with real targets, using a command-line interface. A development team using an IDE for embedded development should always consider providing an option to build and test any software through a command-line alternate strategy.

While some complexity of the toolchain can be abstracted with a GUI, it is useful to understand the functions of the set of applications under the hood. The remaining sections of this chapter explore the GCC toolchain, the most popular cross-architecture set of compilers for many 32-bit microcontrollers.

The GCC toolchain

While in the case of the IDE, its complexity is abstracted through the user interface, a toolchain is a set of standalone software applications, each one serving a specific purpose.

GCC is one of the reference toolchains to build embedded systems due to its modular structure allowing backends for multiple architectures. Thanks to its open source model, and the flexibility in building tailored toolchains from it, GCC-based toolchains are among the most popular development tools in embedded systems.

Building software using a command-line-based toolchain has several advantages, including the possibility of automating the intermediate steps that would build all the modules up from the source code into the final image. This is particularly useful when it is required to program multiple devices in a row or to automate builds on a continuous integration server.

ARM distributes the GNU Arm Embedded Toolchain for all the most popular development hosts. Toolchains are prefixed with a triplet describing the target. In the case of the GNU Arm Embedded Toolchain, the prefix is arm-none-eabi, indicating that the cross compiler backend is configured to produce objects for ARM, with no specific support for an operating system API, and with the embedded ABI.

The cross compiler

The cross compiler distributed with a toolchain is a variant of GCC, with the backend configured to build object files that contain machine code for a specific architecture. The output of the compilation is one set of object files containing symbols that can only be interpreted by the specific target. Arm-none-eabi-gcc, the GCC variant provided by ARM to build software for microcontrollers, can compile C code into machine instructions and CPU optimizations for several different targets. Each architecture needs its own specific toolchain that will produce target-specific executables.

The GCC backend for the ARM architecture supports several machine-specific options to select the correct instruction set for the CPU and the machine-specific optimization parameters.

The following table lists some of the ARM-specific machine options available on the GCC backend as -m flags:

Table 2.3 – Architecture-specific compiler options for GCC ARM

To compile code that is compatible with a generic ARM Cortex M4, the -mthumb and -mcpu=cortex-m4 options must be specified every time the compiler is invoked:

$ arm-none-eabi-gcc -c test.c -mthumb -mcpu=cortex-m4

The test.o file that is the result of this compile step is very different from the one that can be compiled, from the same source, using the gcc host. The difference can be better appreciated if, instead of the two object files, the intermediate assembly code is compared. The compiler is, in fact, capable of creating intermediate assembly code files instead of compiled and assembled objects when it is invoked with the -S option.

In a similar way to the host GCC compiler, there are different levels of possible optimization available to activate. In some cases, it makes sense to activate the size optimization to generate smaller object files. It is preferable, though, that the non-optimized image can fit the flash during the development to facilitate the debugging procedures, as optimized code flow is more difficult to follow when the compiler may change the order of the execution of the code and hide away the content of some variables. The optimization parameter can be provided at the command line to select the desired optimization level:

Table 2.4 – GCC levels of optimization

Another generic GCC command-line option that is often used while debugging and prototyping is the -g flag, which instructs the compiler to keep the debugging-related data in the final object in order to facilitate access to functions’ and variables’ readable handles while running within the debugger.

To inform the compiler that we are running a bare-metal application, the -ffreestanding command-line option is used. In GCC jargon, a freestanding environment is defined by the possible lack of a standard library in the linking step, and most importantly, this option alerts the compiler that it should not expect to use the main function as the entry point of the program or provide any preamble code before the beginning of the execution. This option is required when compiling code for the embedded platforms, as it enables the boot mechanism described in Chapter 4, The Boot-Up Procedure.

The GCC program supports many more command-line options than those quickly introduced here. For a more complete overview of the functionalities offered, please refer to the GNU GCC manual, available at https://gcc.gnu.org/onlinedocs/.

To integrate the cross compiling toolchain in the automated build using Make, a few changes are required in the makefile.

Assuming that the toolchain is correctly installed on the development host and reachable in its executing path, it is sufficient to change the default compiler command using the CC Make variable in the makefile:

CC=arm-none-eabi-gcc

The custom command-line options required to run the compile options may be exported through the CFLAGS variable:

CFLAGS=-mthumb -mcpu=cortex-m4 -ffreestanding

Using default makefile variables, such as CC and CFLAGS, enables implicit makefile rules, building object files from C sources with the same name, and a custom compiler configuration.

Compiling the compiler

Binary distributions of the GCC toolchain are available to download for several specific targets and host machines. To compile the code for the ARM Cortex-M microprocessors, the arm-none-eabi toolchain is made available for most GNU/Linux distributions. However, in some cases, it might be handy to build the toolchain entirely from the sources. This might be, for example, when the compiler for a certain target does not exist yet or is not shipped in binary format for our favorite development environment. This process is also useful to better understand the various components that are required to build the tools.

Crosstool-NG is an open source project that consists of a set of scripts aimed at automating the process of creating a toolchain. The tool retrieves the selected version of every component, then creates an archive of the toolchain that can be redistributed in binary form. This is normally not necessary, while sometimes useful when it is necessary to modify the sources for a specific component, such as, for example, the C libraries that are finally integrated into the toolchain. It is easy to create a new configuration in crosstool-NG, thanks to its configurator, based on the Linux menuconfig kernel. After installing crosstool-NG, the configurator can be invoked by using the following:

$ ct-ng menuconfig

Once the configuration has been created, the build process can be started. Since the operation requires retrieving all the components, patching them, and building the toolchain, it may take several minutes, depending on the speed of the host machine and the internet connection, to retrieve all the components. The build process can be started by issuing the following:

$ ct-ng build

Predefined configurations are available for compiling commonly used toolchains, mostly for targets running Linux. When compiling a toolchain for a Linux target, there are a few C libraries to choose from. In our case, since we want a bare-metal toolchain, newlib is the default choice. Several other libraries provide an implementation of a subset of the C standard library, such as uClibc and musl. The newlib library is a small cross-platform C library mostly designed for embedded systems with no operating system on board, and it is provided as the default in many GCC distributions, including the arm-none-eabi cross compiler distributed by ARM.

Linking the executable

Linking is the last step in the creation of the ELF file. The cross compiling GCC groups all the object files together and resolves the dependencies among symbols. By passing the -T filename option at the command line, the linker is asked to replace the default memory layout for the program with a custom script, contained in the filename.

The linker script is a file containing the description of the memory sections in the target, which need to be known in advance in order for the linker to place the symbols in the correct sections in flash, and instruct the software components about special locations in the memory mapping area that can be referenced in the code. The file is recognizable by its .ld extension, and it is written in a specific language. As a rule of thumb, all the symbols from every single compiled object are grouped in the sections of the final executable image.

The script can interact with the C code, exporting symbols defined within the script and following indications provided in the code using GCC-specific attributes associated with symbols. The __attribute__ keyword is provided by GCC to be put in front of the symbol definition to activate GCC-specific, non-standard attributes for each symbol.

Some GCC attributes can be used to communicate to the linker about the following:

• Weak symbols, which can be overridden by symbols with the same name
• Symbols to be stored in a specific section in the ELF file, defined in the linker script
• Implicitly used symbols, which prevent the linker from discarding the symbol because it is referred to nowhere in the code

The weak attribute is used to define weak symbols, which can be overridden anywhere else in the code by another definition with the same name. Consider, for example, the following definition:

void __attribute__(weak) my_procedure(int x) {/* do nothing */}

In this case, the procedure is defined to do nothing, but it is possible to override it anywhere else in the code base by defining it again, using the same name, but this time without the weak attribute:

void my_procedure(int x) { y = x; }

The linker step ensures that the final executable contains exactly one copy of each defined symbol, which is the one without the attribute, if available. This mechanism introduces the possibility of having several different implementations of the same functionality within the code, which can be altered by including different object files in the linking phase. This is particularly useful when writing code that is portable to different targets while still maintaining the same abstractions.

Besides the default sections required in the ELF description, custom sections may be added to store specific symbols, such as functions and variables, at fixed memory addresses. This is useful when storing data at the beginning of a flash page, which might be uploaded to flash at a different time than the software itself. This is the case for target-specific settings in some cases.

Using the custom GCC section attribute when defining a symbol ensures that the symbol ends up at the desired position in the final image. Sections may have custom names as long as an entry exists in the linker to locate them. The section attribute can be added to a symbol definition as follows:

const uint8_t
 __attribute__((section(".keys")))
 private_key[KEY_SIZE] = {0};

In this example, the array is placed in the .keys section, which requires its own entry in the linker script as well.

It is considered good practice to have the linker discard the unused symbols in the final image, especially when using third-party libraries that are not completely utilized by the embedded application. This can be done in GCC using the linker garbage collector, activated via the -gc-sections command-line option. If this flag is provided, the sections that are unused in the code are automatically discarded, and the unused symbols will be kept out of the final image.

To prevent the linker from discarding symbols associated with a particular section, the used attribute marks the symbol as implicitly used by the program. Multiple attributes can be listed in the same declaration, separated by commas, as follows:

const uint8_t    __attribute__((used,section(".keys")))
   private_key[KEY_SIZE] = {0};

In this example, the attributes indicate both that the private_key array belongs to the .keys section and that it must not be discarded by the linker garbage collector because it is marked as used.

A simple linker script for an embedded target defines at least the two sections relative to RAM and FLASH mapping and exports some predefined symbols to instruct the assembler of the toolchain about the memory areas. A bare-metal system based on the GNU toolchain usually starts with a MEMORY section, describing the mapping of the two different areas in the system, such as the following:

MEMORY {
  FLASH(rx) : ORIGIN = 0x00000000, LENGTH=256k
  RAM(rwx) : ORIGIN = 0x20000000, LENGTH=64k
}

The preceding code snippet describes two memory areas used in the system. The first block is 256k mapped to FLASH, with the r and x flags indicating that the area is accessible for read and execute operations. This enforces the read-only attribute of the whole area and ensures that no variant sections are placed there. RAM, on the other hand, can be accessed in write mode directly, which means that variables are going to be placed in a section within that area. In this specific example, the target maps the FLASH mapping at the beginning of the address space, while the RAM is mapped starting at 512 MB. Each target has its address space mapping and flash/RAM size, which makes the linker script target-specific.

As mentioned earlier in this chapter, the .text and .rodata ELF sections can only be accessed for reading, so they can safely be stored in the FLASH area since they will not be modified while the target is running. On the other hand, both .data and .bss must be mapped in RAM to ensure that they are modifiable.

Additional custom sections can be added to the script where it is necessary to store additional sections at a specific location in memory. The linker script can also export symbols related to a specific position in memory or to the length of dynamically sized sections in memory, which can be referred to as external symbols and accessed in the C source code.

The second block of statements in the linker script is called SECTIONS and contains the allocation of the sections in specific positions of the defined memory areas. The . symbol, when associated with a variable in the script, represents the current position in the area, which is filled progressively from the lower addresses available.

Each section must specify the area where it has to be mapped. The following example, though still incomplete to run the binary executable, shows how the different sections can be deployed using the linker script. The .text and .rodata sections are mapped in the flash memory:

SECTIONS
{
    /* Text section (code and read-only data) */
    .text :
    {
        . = ALIGN(4);
        _start_text = .;
        *(.text*) /* code */
        . = ALIGN(4);
        _end_text = .;
        *(.rodata*) /* read only data */
        . = ALIGN(4);
        _end_rodata = .;
} > FLASH

The modifiable sections are mapped in RAM, with two special cases to notice here.

The AT keyword is used to indicate the load address to the linker, which is the area where the original values of the variables in .data are stored, while the actual addresses used in the execution are in a different memory region. More details about the load address and the virtual address for the .data section are explained in Chapter 4, The Boot-Up Procedure.

The NOLOAD attribute used for the .bss section ensures that no predefined values are stored in the ELF file for this section. Uninitialized global and static variables are mapped by the linker in the RAM area, which is allocated by the linker:

_stored_data = .;
.data: AT(__stored_data)
{
    . = ALIGN(4);
    _start_data = .;
    *(.data*)
    . = ALIGN(4);
    _start_data = .;
} > RAM
.bss (NOLOAD):
{
    . = ALIGN(4);
    _start_bss = .;
    *(.bss*)
    . = ALIGN(4);
    _end_bss = .;
} > RAM

The alternative way to force the linker to keep sections in the final executable, avoiding their removal due to the linker garbage collector, is the use of the KEEP instruction to mark sections. Please note that this is an alternative to the __attribute__((used)) mechanism explained earlier:

.keys :
{
    . = ALIGN(4);
    *(.keys*) = .;
    KEEP(*(.keys*));
} > FLASH

It is useful, and advisable in general, to have the linker create a .map file alongside the resultant binary. This is done by appending the -Map=filename option to the link step, such as in the following:

$ arm-none-eabi-ld -o image.elf object1.o object2.o 
-T linker_script.ld -Map=map_file.map

The map file contains the location and the description of all the symbols, grouped by sections. This is useful for looking for the specific location of symbols in the image, as well as for verifying that useful symbols are not accidentally discarded due to a misconfiguration.

Cross compiling toolchains provide standard C libraries for generic functionalities, such as string manipulation or standard type declarations. These are substantially a subset of the library calls available in the application space of an operating system, including standard input/output functions. The backend implementation of these functions is often left to the applications, so calling a function from the library that requires interaction with the hardware, such as printf, implies that a write function is implemented outside of the library, providing the final transfer to a device or peripheral.

The implementation of the backend write function determines which channel would act as the standard output for the embedded application. The linker is capable of resolving the dependencies towards standard library calls automatically, using the built-in newlib implementation. To exclude the standard C library symbols from the linking process, the -nostdlib option can be added to the options passed to GCC during the linking step.

Binary format conversion

Despite containing all the compiled symbols in binary format, an ELF file is prefixed with a header that contains a description of the content and pointers to the positions where the sections start within the file. All this extra information is not needed to run on an embedded target, so the ELF file produced by the linker has to be transformed into a plain binary file. A tool in the toolchain, called objcopy, converts images from one standard format to others, and what is generally done is a conversion of the ELF into a raw binary image without altering the symbols. To transform the image from ELF to binary format, invoke the following:

$ arm-none-eabi-objcopy -I elf -O binary image.elf image.bin

This creates a new file, called image.bin, from the symbols contained in the original ELF executable, which can be uploaded to the target.

Even if not suitable in general for direct upload on the target with third-party tools, it is possible to load the symbols through the debugger and upload them to the flash address. The original ELF file is also useful as the target of other diagnostic tools in the GNU toolchain, such as nm and readelf, which display the symbols in each module, with their type and relative address within the binary image. Furthermore, by using the objdump tool on the final image, or even on single object files, several details about the image can be retrieved, including the visualization of the entire assembly code, using the -d disassemble option:

arm-none-eabi-objdump -d image.elf

At this point, the toolchain has provided us with all the artifacts needed to run, debug, and analyze the compiled software on a target microcontroller. In order to transfer the image or start a debugging session, we need additional specific tools, described in the next section.

Interacting with the target

For development purposes, embedded platforms are usually accessed through a JTAG or an SWD interface. Through these communication channels, it is possible to upload the software onto the flash of the target and access the on-chip debug functionality. Several self-contained JTAG/SWD adapters on the market can be controlled through a USB from the host, while some development boards are equipped with an extra chip controlling the JTAG channel that connects to the host through a USB.

A powerful generic open source tool to access JTAG/SWD functionalities on the target is the Open On-Chip Debugger (OpenOCD). Once properly configured, it creates local sockets that can be used as a command console and for interaction with the debugger frontend. Some development boards are distributed with additional interfaces to communicate with the core CPU. For example, STMicroelectronics prototyping boards for Cortex-M are rarely shipped without a chip technology called ST-Link, which allows direct access to debug and flash manipulation functionalities. Thanks to its flexible backend, OpenOCD can communicate with these devices using different transport types and physical interfaces, including ST-Link and other protocols. Several different boards are supported and the configuration files can be found by OpenOCD.

When started, OpenOCD opens two local TCP server sockets on preconfigured ports, providing communication services with the target platform. One socket provides an interactive command console that can be accessed through Telnet, while the other is a GDB server used for remote debugging, as described in the next section.

OpenOCD is distributed along with two sets of configuration files that describe the target microcontroller and peripherals (in the target/ directory), and the debugging interface used to communicate to it via JTAG or SWD (in the interface/ directory). A third set of configuration files (in the board/ directory) contain configuration files for well-known systems, such as development boards equipped with an interface chip, which combines both interfaces and target settings by including the correct files.

In order to configure OpenOCD for the STM32F746-Discovery target, we can use the following openocd.cfg configuration file:

telnet_port 4444
gdb_port 3333
source [find board/stm32f7discovery.cfg]

The board-specific configuration file, which was imported from openocd.cfg, through the source directive, instructs OpenOCD to use the ST-Link interface to communicate with the target and sets all the CPU-specific options for the STM32F7 family of microcontrollers.

The two ports specified in the main configuration file, using the telnet_port and gdb_port directives, instruct OpenOCD to open two listening TCP sockets.

The first socket, often referred to as the monitor console, can be accessed by connecting to the local 4444 TCP port, using a Telnet client from the command line:

$ telnet localhost 4444
Open On-Chip Debugger
>

The sequence of OpenOCD directives to initialize, erase the flash, and transfer the image starts with the following:

> init
> halt
> flash probe 0

The execution is stopped at the beginning of the software image. After the probe command, the flash is initialized, and OpenOCD will print out some information, including the address mapped to write on the flash. The following information shows up with the STM32F746:

device id = 0x10016449
flash size = 1024kbytes
flash "stm32f2x" found at 0x08000000

The geometry of the flash can be retrieved using this command:

> flash info 0

Which, on STM32F746 shows as the following:

#0 : stm32f2x at 0x08000000, size 0x00100000, buswidth 0, chipwidth 0
# 0: 0x00000000 (0x8000 32kB) not protected
# 1: 0x00008000 (0x8000 32kB) not protected
# 2: 0x00010000 (0x8000 32kB) not protected
# 3: 0x00018000 (0x8000 32kB) not protected
# 4: 0x00020000 (0x20000 128kB) not protected
# 5: 0x00040000 (0x40000 256kB) not protected
# 6: 0x00080000 (0x40000 256kB) not protected
# 7: 0x000c0000 (0x40000 256kB) not protected
STM32F7[4|5]x - Rev: Z

This flash contains eight sectors. If the OpenOCD target supports it, the flash can be completely erased by issuing the following command from the console:

> flash erase_sector 0 0 7

Once the flash memory is erased, we can upload a software image to it, linked and converted to raw binary format using the flash write_image directive. As the raw binary format does not contain any information about its destination address in the mapped area, the starting address in the flash must be provided as the last argument, as follows:

> flash write_image /path/to/image.bin 0x08000000

These directives can be appended to the openocd.cfg file, or to different configuration files, in order to automate all the steps needed for a specific action, such as erasing the flash and uploading an updated image.

Some hardware manufacturers offer their own set of tools to interact with the devices. STMicroelectronics devices can be programmed using the ST-Link utilities, an open source project that includes a flash tool (st-flash), and a GDB server counterpart (st-util). Some platforms have built-in bootloaders that accept alternative formats or binary transfer procedures. A common example is Device Firmware Upgrade (DFU), which is a mechanism to deploy firmware on targets through a USB. The reference implementation on the host side is dfu-util, which is a free software tool.

Each tool, either generic or specific, tends to meet the same goal of communicating with the device and providing an interface for debugging the code, although often exposing a different interface toward the development tools.

Most IDEs provided by manufacturers to work with a specific family of microcontrollers incorporate in the IDE their own tools or third-party applications to access flash mapping and control the execution on the target. While, on one hand, they promise to hide the unnecessary complexity of the operation and provide firmware upload in one click, on the other, they generally do not provide a convenient interface for programming multiple targets at the same time, or at least efficiently, when it comes to production in large batches requiring to upload of the initial factory firmware.

Knowing the mechanisms and procedures from a command-line interface allows for understanding what is happening behind the scenes every time a new firmware is uploaded to the target, and anticipating the issues that would impact the life cycle during this phase.

The GDB session

Regardless of the programmer’s accuracy or the complexity of the project we are working on, most of the development time will be spent trying to understand what our software does, or most likely, what has gone wrong and why the software is not behaving as we would expect when the code was written for the first time. The debugger is the most powerful tool in our toolchain, allowing us to communicate directly with the CPU, place breakpoints, control the execution flow instruction by instruction, and check the values of CPU registers, local variables, and memory areas. Good knowledge of the debugger means less time spent trying to figure out what is going on, and a more effective hunt for bugs and defects.

The arm-none-eabi toolchain includes a GDB capable of interpreting the memory and the register layout of the remote target and can be accessed with the same interfaces as the host GDB, provided that its backend can communicate with the embedded platform, using OpenOCD or a similar host tool providing communication with the target through the GDB server protocol. As previously described, OpenOCD can be configured to provide a GDB server interface, which in the proposed configuration is on port 3333.

After starting arm-none-eabi-gdb, we may connect to the running tool using the GDB target command. Connecting to the GDB server while OpenOCD is running can be done using the target command:

> target remote localhost:3333

All GDB commands can be abbreviated, so the command often becomes the following:

> tar rem :3333

Once connected, the target would typically stop the execution, allowing GDB to retrieve the information about the instruction that is currently being executed, the stack trace, and the values of the CPU registers.

From this moment on, the debugger interface can be used normally to step through the code, place breakpoints and watchpoints, and inspect and alter CPU registers and writable memory areas at runtime.

GDB can be used entirely from its command-line interface, using shortcuts and commands to start and stop the execution, and access memory and registers.

The following reference table enumerates a few of the GDB commands available in a debug session and provides a quick explanation of their usage:

Table 2.5 – A few commonly used GDB commands

GDB is a very powerful and complete debugger, and the commands that have been shown in this section are a small portion of its actual potential. We advise you to discover the other features offered by GDB by going through its manual in order to find the set of commands that best fit your needs.

IDEs often offer a separate graphic mode to deal with debugging sessions, which is integrated with the editor and allows you to set breakpoints, watch variables, and explore the content of memory areas while the system is running in debug mode.

Validation

Debugging alone, or even simple output analysis is often not enough when verifying system behavior and identifying issues and unwanted effects in the code. Different approaches may be taken to validate the implementation of single components, as well as the behavior of the entire system under different conditions. While, in some cases, the results can be directly measurable from the host machine, in more specific contexts, it is often difficult to reproduce the exact scenario or to acquire the necessary information from the system output.

External tools may come in handy, especially in the analysis of communication interfaces and network devices in a more complex, distributed system. In other cases, single modules can be tested off-target using simulated or emulated environments to run smaller portions of the code base.

Different tests, validation strategies, and tools are considered in this section to provide solutions for any scenario.

Functional tests

Writing test cases before writing the code is generally considered an optimal practice in modern programming. Writing tests first not only speeds up the development phases but also improves the structure of the workflow. By setting clear and measurable goals from the beginning, it is harder to introduce conceptual defects in the design of the single components, and it also forces a clearer separation among the modules. More specifically, an embedded developer has less possibility to verify the correct behavior of the system through direct interaction; thus test-driven development (TDD) is the preferred approach for the verification of single components as well as the functional behavior of the entire system, as long as the expected results can be directly measurable from the host system.

However, it must be considered that testing often introduces dependencies on specific hardware, and sometimes the output of an embedded system can only be validated through specific hardware tools or in a very unique and peculiar usage scenario. In all these cases, the usual TDD paradigm is less applicable, and the project can instead benefit from a modular design to give the possibility to test as many components as possible in a synthetic environment, such as emulators or unit test platforms.

Writing tests often involves programming the host so that it can retrieve information about the running target while the embedded software is executing or alongside an ongoing debugging session while the target executes in between breakpoints. The target can be configured to provide immediate output through a communication interface, such as a UART-based serial port, which can, in turn, be parsed by the host. It is usually more convenient to write test tools on the host using a higher-level interpreted programming language to better organize the test cases and easily integrate the parsing of test results using regular expressions. Python, Perl, Ruby, and other languages with similar characteristics, are often a good fit for this purpose, also thanks to the availability of libraries and components designed for collecting and analyzing test results and interacting with continuous integration engines. A good organization of the test and verification infrastructure contributes more than everything else to the stability of the project because regressions can be detected at the right time only if all the existing tests are repeated at every modification. Constantly running all the test cases while the development is ongoing not only improves the efficiency of detecting undesired effects as early as possible but helps keep the development goals visible at all times by directly measuring the number of failures and makes the refactoring of components more affordable at any stage in the project lifetime.

Efficiency is the key because embedded programming is an iterative process with several steps being repeated over and over, and the approach required from the developers is much more predictive than reactive.

Hardware tools

If there is a tool that is absolutely indispensable in assisting embedded software developers, it is the logic analyzer. By scoping the input and output signals involving the microcontroller, it is possible to detect the electrical behavior of the signals, their timing, and even the digital encoding of the single bits in the interface protocols. Most logic analyzers can identify and decode sequences of symbols by sensing the voltage of the wires, which is often the most effective way to verify that protocols are correctly implemented and compliant with the contracts to communicate with peripherals and network endpoints. While historically available only as standalone dedicated computers, a logic analyzer is often available in other forms, such as electronic instruments that can be connected to the host machine using USB or Ethernet interfaces, and use PC-based software to capture and decode the signals. The result of this process is a complete discrete analysis of the signals involved, which are sampled at a constant rate and then visualized on a screen.

While a similar task can be performed by oscilloscopes, they are often more complex to configure than logic analyzers when dealing with discrete signals. Nevertheless, an oscilloscope is the best tool for the analysis of analog signals, such as analog audio and communication among radio transceivers. Depending on the task, it might be better to use one or the other, but in general, the biggest advantage of a logic analyzer is that it provides better insight into discrete signals. Mixed-signal logic analyzers are often a good compromise between the flexibility of an oscilloscope, with the simplicity and insights of discrete signal-logic analysis.

Oscilloscopes and logic analyzers are often used to capture the activity of signals in a specific time window, which might be challenging to synchronize with the running software. Instead of capturing those signals continuously, the beginning of the capture can be synchronized with a physical event, such as a digital signal changing its value for the first time or an analog signal crossing a predefined threshold. This is done by configuring the instrument to initiate the capture using a trigger, which guarantees that the information captured only contains a time slice that is interesting for the ongoing diagnostic.

Testing off-target

Another efficient way to speed up the development is by limiting the interaction, as much as possible, with the actual target. This is, of course, not always possible, especially when developing device drivers that need to be tested on actual hardware, but tools and methodologies to partially test the software directly on the development machine exist.

Portions of code that are not CPU-specific can be compiled for the host machine architecture and run directly, as long as their surroundings are properly abstracted to simulate the real environment. The software to test can be as small as a single function, and in this case, a unit test can be written specifically for the development architecture.

Unit tests are, in general, small applications that verify the behavior of a single component by feeding them with well-known input and verifying its output. Several tools are available on a Linux system to assist in writing unit tests. The check library provides an interface for defining unit tests by writing a few preprocessor macros. The result is small self-contained applications that can be run every time the code is changed, directly on the host machine. Those components of the system that the function under test depends on are abstracted using mocks. For example, the following code detects and discards a specific escape sequence, Esc + C, from the input from a serial line interface, reading from the serial line until the \0 character is returned:

int serial_parser(char *buffer, uint32_t max_len)
{
  int pos = 0;
  while (pos < max_len) {
    buffer[pos] = read_from_serial();
    if (buffer[pos] == (char)0)
      break;
    if (buffer[pos] == ESC) {
       buffer[++pos] = read_from_serial();
       if (buffer[pos] == 'c')
         pos = pos - 1;
         continue;
    }
    pos++;
  }
  return pos;
}

A set of unit tests to verify this function using a check test suite may look like the following:

START_TEST(test_plain) {
  const char test0[] = "hello world!";
  char buffer[40];
  set_mock_buffer(test0);
  fail_if(serial_parser(buffer, 40) != strlen(test0));
  fail_if(strcmp(test0,buffer) != 0);
}
END_TEST

Each test case can be contained in its START_TEST()/END_TEST block and provide a different initial configuration:

START_TEST(test_escape) {
  const char test0[] = "hello world!";
  const char test1[] = "hello \033cworld!";
  char buffer[40];
  set_mock_buffer(test1);
  fail_if(serial_parser(buffer, 40) != strlen(test0));
  fail_if(strcmp(test0,buffer) != 0);
}
END_TEST
START_TEST(test_other) {
  const char test2[] = "hello \033dworld!";
  char buffer[40];
  set_mock_buffer(test2);
  fail_if(serial_parser(buffer, 40) != strlen(test2));
  fail_if(strcmp(test2,buffer) != 0);
}
END_TEST

This first test_plain test ensures that a string with no escape characters is parsed correctly. The second test ensures that the escape sequence is skipped, and the third one verifies that a similar escape string is left untouched by the output buffer.

Serial communication is simulated using a mock function that replaces the original serial_read functionality provided by the driver when running the code on the target. This is a simple mock that feeds the parser with a constant buffer that can be reinitialized using the set_serial_buffer helper function. The mock code looks like this:

static int serial_pos = 0;
static char serial_buffer[40];
char read_from_serial(void) {
  return serial_buffer[serial_pos++];
}
void set_mock_buffer(const char *buf)
{
  serial_pos = 0;
  strncpy(serial_buffer, buf, 20);
}

Unit tests are very useful to improve the quality of the code, but of course, achieving high code coverage consumes a large amount of time and resources in the economy of the project. Functional tests can also be run directly in the development environment by grouping functions into self-contained modules and implementing simulators that are slightly more complex than mocks for specific test cases. In the example of the serial parser, it would be possible to test the entire application logic on top of a different serial driver on the host machine, which is also able to simulate an entire conversation over the serial line, and interact with other components in the system, such as virtual terminals and other applications generating input sequences.

While covering a larger portion of the code within a single test case, the complexity of the simulated environment increases, and so does the amount of work required to reproduce the surroundings of the embedded system on the host machine. Nevertheless, it is good practice, especially when they could be used as verification tools throughout the whole development cycle and even integrated into the automated test process.

Sometimes, implementing a simulator allows for a much more complete set of tests, or it might be the only viable option. Think, for example, about those embedded systems using a GPS receiver for positioning: testing the application logic with negative latitude values would be impossible while sitting in the northern hemisphere, so writing a simulator that imitates the data coming from such a receiver is the quickest way to verify that our final device will not stop working across the equator.

Emulators

Another valid approach to running the code on the development machine, which is much less invasive for our code base and loosens the specific portability requirements, is emulating the whole platform on the host PC. An emulator is a computer program that can replicate the functionality of an entire system, including its core CPU, memory, and a set of peripherals. Some of the modern virtualization hypervisors for PCs are derived from QEMU, a free software emulator capable of virtualizing entire systems, even with a different architecture from those of the machine where it runs. Since it contains the full implementation of the instruction set of many different targets, QEMU can run the firmware image, which had been compiled for our target, in a process on top of the development machine’s operating system. One of the supported targets that can run ARM Cortex-M3 microcode is lm3s6965evb, an old Cortex-M-based microcontroller, no longer recommended for new designs by the manufacturer, that is fully supported by QEMU.

Once a binary image has been created using lm3s6965evb as a target, and properly converted to raw binary format using objcopy, a fully emulated system can be run by invoking QEMU as follows:

$ qemu-system-arm -M lm3s6965evb --kernel image.bin

The --kernel option instructs the emulator to run the image at startup, and while it might sound misnamed, it is called kernel because QEMU is widely used to emulate headless Linux systems on other synthetic targets. Similarly, a convenient debugging session can be started by using QEMU’s built-in GDB server through the -gdb option, which can also halt the system until our GDB client is connected to it:

$ qemu-system-arm -M lm3s6965evb --kernel image.bin -nographic -S -gdb tcp::3333

In the same way, as with the real target, we can connect arm-none-eabi-gdb to TCP port 3333 on localhost and start debugging the software image exactly as it was running on the actual platform.

The limit of the emulation approach is that QEMU can only be used to debug generic features that do not involve interaction with actual modern hardware. Nevertheless, running QEMU with a Cortex-M3 target can be a quick way to learn about generic Cortex-M features, such as memory management, system interrupt handling, and processor modes, because many features of the Cortex-M CPU are accurately emulated.

More accurate emulation of microcontroller systems can be achieved using Renode (https://renode.io). Renode is an open source, configurable emulator for many different microcontrollers and CPU-based embedded systems. The emulation includes peripherals, sensors, LEDs, and even wireless and wired interfaces to interconnect multiple emulated systems and the host network.

Renode is a desktop application with a command-line console. A single configuration file must be provided from the command-line invocation, with several platforms and development board configurations provided under the /scripts directory. This means that once installed, the emulator for the STM32F4 discovery board can be started by invoking the following command:

$ renode /opt/renode/scripts/single-node/stm32f4_discovery.resc

This command will load the demo firmware on an emulated STM32F4 target flash memory and redirect the I/O of one of the emulated UART serial ports to a console in a new window. To start the demo, type start in the Renode console.

The example script comes with a demo firmware image running Contiki OS. The firmware image is loaded by the script via the Renode command:

sysbus LoadELF $bin

Where $bin is a variable pointing to the path (or the URL) of the firmware ELF file to load on the emulated flash memory. This option, as well as the UART analyzer port and other specific commands to execute when the emulator is started, can be easily changed by customizing the script file.

Renode integrates a GDB server that can be spawned from the Renode console or the startup script before starting the emulation, for example, using the following:

machine StartGdbServer 3333

In this case, 3333 is the TCP port the GDB server will be listening to, as in the other cases with QEMU and a debugger on the physical target.

Unlike QEMU, which is a very generic emulator, Renode is a project created with the purpose of assisting embedded developers throughout the entire life cycle. The possibility to emulate different complete platforms, creating mocks for sensors on several architectures, including RISC-V, makes it a unique tool to automate testing on multiple targets quickly or test on systems even when the actual hardware is not available.

Last but not least, thanks to its own scripting language, Renode is perfectly integrated with test automation systems, where the execution of the emulated target can be started, stopped, and resumed, and the configuration of all devices and peripherals altered while the test is running.

The approaches proposed for the definition of test strategies take into account different scenarios. The idea has been to introduce a range of possible solutions for software validation, from lab equipment to tests off-target in simulated and emulated environments, for the developer to choose from in a specific scenario.

Summary

This chapter introduced the tools for working on the development of embedded systems. A hands-on approach has been proposed to get you up and running with the toolchain and the utilities required to communicate with the hardware platform. Using appropriate tools can make embedded development easier and shorten workflow iterations.

In the next chapter, we provide indications for workflow organization when working with larger teams. Based on real-life experiences, we propose solutions for splitting and organizing tasks, executing tests, iterating throughout the phases of design, and the definition and implementation of an embedded project.

3

Architectural Patterns

Starting an embedded project from scratch means progressively stepping towards the final solution by going through all the research and development phases and considering the synergy among all the parts involved.

Software development needs to evolve accordingly throughout these phases. In order to get the best results without excessive overhead, there are a few best practices to follow and tools to discover.

This chapter describes a possible approach toward configuration-management tools and design patterns, based on real-life experiences. Describing this approach may help you to understand the dynamics of working in a team focused on producing an embedded device or solution.

We will discuss the following topics in this chapter:

• Configuration management
• Source code organization
• The life cycle of an embedded project
• Security considerations

By the end of the chapter, you will gain an overview of the architectural patterns useful for designing the system based on the specifications and the platform limits.

Configuration management

When working as a team, coordination and synchronization can be optimized to improve efficiency. Tracking and controlling the development life cycle smoothens the development flow, cutting downtime and costs.

The most important tools known to help manage the software life cycle are the following:

• Revision control
• Issue tracking
• Code reviews
• Continuous integration

Different options exist for the four categories. The source code is synchronized among developers through a revision control system. Issue tracking systems (ITSs) usually consist of web platforms that keep track of the activities and known bugs of the system. Code reviews can be encouraged with specific web-based tools and enforced through rules on the revision control systems.

Continuous integration tools ensure that build and test execution tasks are scheduled to automatically execute, periodically or upon changes in the code, collecting test results and notifying the developers about regressions.

Revision control

No matter whether you are working alone or in a large development team, properly keeping track of the development progress is extremely important. Revision control tools allow developers to roll back failed experiments at any time with the press of a button, and visiting its history gives a clear view of how the project is evolving at any time.

A revision control system, also known as a version control system, or VCS, encourages cooperation by making merge operations easier. The most updated official version is referred to as a trunk, master, or main branch, depending on the VCS in use. VCSs offer, among other things, fine-grained access control and authorship attribution down to a single commit.

One of the most modern and widely used open source VCSs is Git. Originally created as the VCS for the Linux kernel, Git offers a range of features but, most importantly, provides a flexible mechanism to allow switching among different versions and feature branches quickly and reliably and facilitates the integration of conflicting modifications in the code.

Note

Git terminology is used in this book when describing specific activities related to the VCS.

A commit is a VCS action that results in a new version of the repository. The repository keeps track of the sequence of commits and the changes introduced in each version in a hierarchical structure:

• Branch: A linear sequence of commits is a branch.
• HEAD: The latest version in a branch is called HEAD.
• master: Git refers to the main development branch as a master. The master branch is the main focus of the development. Bug fixes and minor changes may be committed directly to the master.
• Feature branches: These are created for self-contained tasks in progressing and ongoing experiments, which will eventually be merged into the master. When not abused, feature branches are a perfect fit when working in a smaller sub-team on a task and can simplify the code review process, allowing developers to work simultaneously on separate branches, and concentrate the validation of completed tasks as single merge requests.

A merge operation consists of joining together two versions from two different branches that may have diverged and present conflict in the code throughout the development. Some merges are trivial and are automatically resolved by the VCS, while others may require manual fixing.

Using meaningful and verbose commit messages improves the readability of the history of the repository and can help to track regressions later on. Tags can be used to track intermediate versions that are released and distributed.

Tracking activities

Keeping track of activities and tasks can be simplified by using ITS. Some tools can be directly linked to the revision control system so that tasks can be linked to specific commits in the repository and vice versa. This is, in general, a good idea, as it is possible to have a good overview of what has been changed to accomplish a specific task.

At first, tasking out the specifications into short activities facilitates the approach to development. Ideally, tasks are as small as possible and may be grouped by category. Later on, priorities can be set based on intermediate goals and taking into account the availability of the final hardware. Tasks created should be grouped into intermediate milestones, which some tools refer to as blueprints, so that the overall progress towards an intermediate deliverable can be measured based on the progress made on single tasks.

ITS can be used to track actual issues in the project. A bug report should be extensive enough for other developers to understand the symptoms and reproduce the behavior that proves that there is a defect in the code. Ideally, final users and early adopters should be able to add new issues to the tracking system, so the tracking system can be used to track all communication with the development team. Community-based open source projects should provide a publicly accessible ITS interface to users.

Bug-fixing activities generally get a higher priority than development tasks, except in a few cases, for instance, when the bug is the effect of a temporary approximation done by an intermediate prototype, which is expected to be fixed in the next iteration. When a bug affects the behavior of the system, which was proven to work beforehand, it must be marked as a regression. This is important because regressions can usually be handled differently than normal bugs, as it is possible to track them down to a single commit using revision control tools.

Repository control platforms provide several tools, including source code history browsing and the issue-tracking features described earlier. GitLab is a free and open source implementation of such repository control platforms, which can be installed to run as a self-hosted solution. Community projects are often hosted on social coding platforms, such as GitHub, which aim to facilitate contributions to open source and free software projects.

Code reviews

Often integrated into ITS tools, code reviews facilitate team cooperation by encouraging the critical analysis of the changes proposed to the code base, which can be useful to detect potential issues before the proposed changes make it to the master branch. Depending on the project requirements, code reviews may be recommended, or even enforced by the team, to increase the quality of the code and early detection of defects by human inspection.

When properly integrated with the VCS, it is possible to set a threshold of mandatory positive reviews from other members of the team before the commit is considered for merging. It is possible to mandate the review of every single commit in the master branch, using tools such as Gerrit, integrated with the VCS. Depending on the size of the contribution, this mechanism can introduce some unnecessary overhead, so, in most cases, it may be more appropriate to group the changes introduced by a branch altogether to facilitate the review when the branch is proposed for merging into the master. Mechanisms based on merge requests give the reviewers an overview of the changes introduced during the entire development of the modification proposed. In the case of open source projects that accept external contributions, code reviews are a necessary step to validate the changes coming from less trusted contributors, or in general, from outside the team of maintainers. Code reviews are the most powerful tool to prevent malicious code that may be disguised and could not be detected by automatic test and code analysis utilities.

Continuous integration

As previously mentioned, the test-driven approach is crucial in an embedded environment. Automating tests is the best way to promptly detect regressions, and defects in general, while the development is ongoing. Using an automation server, such as Jenkins, it is possible to plan several actions, or jobs, to run responsively (such as at every commit), periodically (such as every Tuesday at 1 a.m.), or manually, upon user requests. Here are a few examples of jobs that can be automated to improve the efficiency of an embedded project:

• Unit tests on the development machine
• System validation tests
• Functional tests on a simulated environment
• Functional tests on a physical target platform
• Stability tests
• Static code analysis
• Generating documentation
• Tagging, versioning, and packaging

The desired level of quality must be decided during design, and test cases must be coded accordingly. Unit test code coverage can be measured using gcov upon each test execution. Some projects intended for life-critical applications may require a very high percentage of coverage for unit tests, but writing a complete set of tests for a complex system has a great impact on the total programming effort and may increase the cost of the development significantly, so researching the right balance between efficiency and quality is advisable in most cases.

A different approach has to be taken with functional tests. All the functionalities implemented on the target should be tested, and tests prepared in advance should be used to define performance indicators and acceptance thresholds. Functional tests should be run in an environment that is as close as possible to the real use case scenario in all those cases where it is impossible to recreate the full use case on the target system and its surroundings.

Source code organization

The code base should contain all the source code, third-party libraries, data, scripts, and automation needed to build the final image. It is a good idea to keep self-contained libraries in separate directories so that they can be easily updated to newer versions by replacing the subdirectory. Makefiles and other scripts can be placed in the project’s root directory.

Application code should be short and synthetic and access the modules abstracting the macro functionalities. Functional modules should describe a process while hiding the details of the underlying implementation, such as reading data from a sensor after it has been properly sampled and processed. Aiming for small, self-contained, and adequately abstracted modules also makes the components of the architecture easier to test. Keeping the majority of the logic for the application components separated from their hardware-specific implementation improves portability across different platforms and allows us to change the peripherals and the interfaces used on the target even during the development phase. Abstracting too much, though, impacts costs, in terms of development effort and resources needed, so the right balance should be researched.

Hardware abstraction

General-purpose prototyping platforms are built and distributed by silicon manufacturers to evaluate microcontrollers and peripherals, so part of the software development may often be performed on these devices even before the design of the final product begins.

The software that can be run on the evaluation board is usually distributed as a reference implementation, in the form of source code or proprietary precompiled libraries. These libraries can be configured and adapted for the final target, to be used as reference hardware abstraction from the beginning, and their settings updated to match changes in the hardware configuration.

On our reference target, support for the hardware components of a generic Cortex-M microcontroller is provided in the form of a library called Cortex Microcontroller Software Interface Standard (CMSIS), distributed by ARM as a reference implementation. Silicon manufacturers derive their specific hardware abstractions by extending CMSIS. An application linked to a target-specific hardware abstraction can access peripherals through its specific API calls and core MCU functionalities through CMSIS.

For code to be portable across different MCUs in the same family, drivers may require an additional level of abstraction on top of the vendor-specific API calls. If the HAL implements multiple targets, it can provide the same API to access generic features across multiple platforms, hiding the hardware-specific implementation under the hood.

The goal of CMSIS and other free software alternatives, such as libopencm3 and unicore-mx, is to group all the generic Cortex-M abstractions and the vendor-specific code for the most common Cortex-M silicon manufacturers while masking the difference among platform-specific calls when controlling the system and the peripherals.

Regardless of the hardware abstraction, some of the code required at the earliest stage of the boot is very specific to each target the software is intended to run on. Each platform has its own specific address space segmentation, interrupt vector, and configuration register displacement. This means that while working on code that is supposed to be portable among different platforms, makefiles and scripts automating the build must be configurable to link using the correct startup code and linker configurations.

The examples contained in this book do not depend on any specific hardware abstraction, as they aim to introduce the control of the system components by directly interacting with the system registers and implementing platform-specific device drivers while focusing on the interaction with the hardware component.

Middleware

Some of the features may already have a well-known solution that has been previously implemented by a single developer, a community, or an enterprise. Solutions may be generic, perhaps designed for a different platform, or even come from outside the embedded world.

In any case, it is always worth looking for libraries for any data transformation, protocol implementation, or subsystem model that might already have been coded and is waiting to be integrated into our project.

Several open source libraries and software components are ready to be included in embedded projects, allowing us to implement a broader set of functionalities. Integrating components from open source projects is particularly useful for delivering standard functionalities. There is a vast choice of well-established open source implementations designed for embedded devices that can be easily integrated into embedded projects, including the following examples:

• Real-time operating systems
• Cryptography libraries
• TCP/IP, 6LoWPAN, and other network protocols
• Transport Layer Security (TLS) libraries
• Filesystems
• IoT message queue protocols
• Parsers

Some components from these categories are described in more detail later in this book.

Basing the software upon an operating system allows us to manage memory areas and thread execution. In this case, threads execute independently from each other, and it is even possible to implement memory separation among threads and between running threads and the kernel. This approach is advisable when the complexity of the design increases or when there are well-known blocking points in the modules that cannot be redesigned. Other libraries usually require multithreading support if an operating system is used, which can be enabled at compile time.

The decision of integrating third-party libraries must be evaluated by measuring the resources needed, in terms of code size and memory used, to perform specific tasks on the target platform. As the whole firmware is distributed as a single executable file, all the licenses of the components must be compatible, and the integration must not violate the license terms of any of its single components.

Application code

The role of the application code is to coordinate, from the highest layer in the project design, all the modules involved, and orchestrate the heuristics of the system. A clean main module that is well-designed allows us to keep a clear view of all the macroscopic blocks of the system, how they are related to each other, and the execution timing of the various components.

Bare-metal applications are built around a main endless loop function, which is in charge of distributing the CPU time among the entry points of the underlying libraries and drivers. The execution happens sequentially, so the code cannot be suspended except by interrupt handlers. For this reason, all the functions and library calls invoked from the main loop are supposed to return as fast as possible because stall points hidden inside other modules may compromise the system’s reactivity, or even block them forever, with the risk of never returning to the main loop. Ideally, in a bare-metal system, every component is designed to interact with the main loop using the event-driven paradigm, with the main loop constantly waiting for events and mechanisms to register callbacks to wake up the application on specific events.

The advantage of the bare-metal, single-thread approach is that synchronization among threads is not needed, all the memory is accessible by any function in the code, and it is not necessary to implement complex mechanisms, such as context and execution model switches. Some basic synchronization mechanisms, however, could still be required when interrupts are on and the flow of execution can be interrupted by external events at any point to execute a specific handler.

If multiple tasks are meant to run on top of an operating system, each task should be confined as much as possible within its own module and explicitly export its start function and public variables as global symbols. In this case, tasks can sleep and call blocking functions, which should implement the OS-specific blocking mechanisms.

Thanks to the flexibility of the Cortex-M CPU, there are different degrees of threads and process separation that can be activated on the system.

The CPU offers multiple tools to facilitate the development of multithreading systems with separation among tasks, multiple execution modes, kernel-specific registers, privilege separation, and memory-segmentation techniques. These options allow architects to define complex systems, more oriented to general-purpose applications, which offer privilege separation and memory segmentation among processes, but also smaller, simpler, more straightforward systems, which do not need these as they are generally designed for a single purpose.

Selecting an executing model that is based on non-privileged threads results in a much more complex implementation of the context changes in the system, and may impact the latency of the real-time operations, which is why bare-metal, single-threaded solutions are still preferred for most real-time applications.

Security considerations

One of the most important aspects to consider when designing a new system is security. Depending on the characteristics of the system, the requirements, and the evaluation of the risks, different countermeasures may be appropriate. Security-enhancing features are often a mix of hardware and software efforts to provide specific protections against known attacks.

Vulnerability management

Software components keep evolving as new features are introduced, and defects are fixed along the way. Some of the defects that are discovered and fixed in a later version may impact the security of the system running outdated software if proper action is not taken promptly. Once vulnerabilities in third-party components are fully disclosed to the public, it is no longer a good choice to keep running outdated code.

Older versions with known defects running on public networks have an increased possibility of becoming the attack surface for attempts to damage the system, take control of the software execution, or steal important data. The best response is prepared very early during the design of the system and consists of planning remote updates using procedures that fit the specific use case, security requirements, and safety levels.

When using third-party libraries, it is appropriate to follow the development of their latest versions and fully understand the impact of the defects that are fixed, especially when those are marked as security issues.

Software cryptography

Cryptography algorithms should be used when appropriate, for example, to encrypt data stored locally or in transit between two systems, authenticate a remote actor on the network, or verify that data has not been altered and comes from a trusted source.

Good cryptography is always based on open, transparent standards so that the security of the system depends solely on the security of the keys, according to the Kerckhoff principle formulated by the Dutch cryptographer Auguste Kerckhoff in the 19th century, rather than on secret mechanisms, with the (false) hope that its implementation will never be disclosed or reverse engineered. Although this last statement should be obvious to whoever has some confidence with the concept of information security, in the past many embedded systems have adopted security by obscurity, as a bad practice of taking shortcuts in the attempt to circumvent the restrictions posed by the lack of appropriate resources to run well-established cryptography primitives on older hardware architectures.

Nowadays, embedded cryptography libraries exist, capable of running the same latest standard algorithms used in PCs and servers in microcontroller-based systems, which meanwhile are becoming more powerful and fit for running the (often CPU-hungry) cryptography math primitives. A complete cryptography library offers a ready-to-use implementation of, typically, three families of algorithms:

• Asymmetric cryptography (RSA, ECC) is based on a pair of keys, private and public, associated with each other. Besides one-way encryption, these algorithms provide other mechanisms, such as authenticating a signature and deriving secondary keys starting from two key pairs, for example, to use as a shared secret by both endpoints communicating over an untrusted medium.
• Symmetric cryptography (AES, ChaCha20) is mostly adopted for bidirectional encryption using the same pre-shared secret key in both directions.
• Hash algorithms (SHA) provide an injective digest calculation and are often used to verify that data has not been altered.

A complete set of algorithms, optimized for embedded systems, is provided by wolfCrypt, the cryptography engine distributed as part of wolfSSL, a professionally maintained open source library that also includes transport layer security protocols, which will be further explained in Chapter 9, Distributed Systems and IoT Architecture.

Hardware cryptography

Taking security aspects under consideration from the very beginning of the design process is important to prematurely identify software and hardware components needed to implement the correct mechanisms. Simply adding a cryptography library does not guarantee an increased level of security in the system unless all the requirements are fulfilled, which often implies some participation from specific hardware components.

Some algorithms require random values with high entropy, which is often hard to obtain on microcontrollers without the help of specific hardware, such as True Random Number Generators (TRNGs).

Other public-key-based cryptography requires trust anchor storage, which means a memory location that cannot be modified at runtime by an attacker, and usually relies on some non-volatile memory features that may be present on the flash memory controller. Finally, to store secret keys, hardware assistance can be needed to provide a secure vault that can only be accessed by privileged code or, in some cases, is never accessible from software and is only allowed to be used in combination with hardware cryptography engines that are coupled with secure storage.

Running untrusted code

As embedded systems become more complex and the code memory increases, it is not unusual to see software components from multiple sources integrated into a single firmware image. Some systems may even provide a software development kit that runs custom code provided by the user.

Others may have an interface that allows you to execute code from a remote location. In all these cases, it would be appropriate to consider separation mechanisms to prevent accidental (or intentional) access to memory areas or peripherals that should not be reachable by actors with lower capabilities.

Most microcontrollers provide two levels of execution privileges, and on some platforms, it is possible to divide the addressable memory space according to those privileges through context switching in the OS. Newer generations of microcontrollers provide TEEs to strictly enforce memory boundaries based on the execution level of the current stage.

The life cycle of an embedded project

Modern development frameworks suggest splitting the work into smaller action points and marking milestones through the project development while producing intermediate working deliverables. Each deliverable focuses on giving a prototype of the entire system, with the missing features temporarily replaced using dummy code.

These recommendations seem particularly effective for embedded projects. In an environment where every error could be fatal to the entire system, working on small action points, one at a time, is an efficient way to promptly identify defects and regressions while working on the code base, provided that a Continuous Integration (CI) mechanism is in place from the early stages of the development. Intermediate milestones should be as frequent as possible, and for this reason, it is advisable to create a prototype of the final system as soon as possible in the development phase. This has to be taken into account when actions are identified, prioritized, and distributed to the team.

Once the steps to reach the goal are defined, we need to find the optimal sequence to produce working prototypes for the intermediate milestones. The dependencies among the development actions are taken into account to sort the priorities for the assignments of the work.

A progressive understanding of the system behavior and hardware constraints may change the view on the system’s architecture while it is under development, as unexpected issues are faced. Changing specifications as a reaction to measurements and evaluations performed on the intermediate prototype may require a major code rework. Throwing away consistent parts of the project to replace them with a new, improved design is often beneficial for the quality of the project and may result in improved productivity in the later stages. This process, known as refactoring, must not be seen as a development overhead whenever it is aimed at improving the design and behavior of the system.

Finally, the process of creating system software includes defining a clear API for the applications to interact with the system in the desired way. Embedded systems provide specific APIs to access system resources most of the time; however, some operating systems and libraries may provide POSIX-like interfaces to access functionalities. In any case, the API is the entry point for the system interfaces and must be designed for usability and well documented.

Defining project steps

When analyzing specifications, defining the required steps, and assigning priorities, several factors may have to be taken into account. Consider designing an air quality monitor device with a PM10 air quality serial sensor, which collects the hourly measurements into the internal flash, then transmits all the statistics daily to a gateway using a wireless transceiver. The target system is a custom board based on Cortex-M MCU, which is adequately sized to run the final software. The final hardware design will not be available until some real-life measurements are done on the transceiver transmitting data to the gateway.

The list of steps to be performed to reach the final goal resulting from these specifications may look as follows:

1. Boot a minimal system on the target (empty main loop).
2. Set up serial port 0 for logging.
3. Set up serial port 1 for the communication to the sensor.
4. Set up a timer.
5. Write the PM10 sensor driver.
6. Create an application that wakes up every hour and reads from the sensor.
7. Write a flash submodule to store/restore measurements.
8. Set up an SPI port to communicate to the radio chip.
9. Write the radio driver.
10. Implement a protocol to communicate with the gateway.
11. Every 24 measurements, the application sends daily measurements to the gateway.

Note

Some of the steps may depend on others, so there are constraints on the order of execution. Some of these dependencies can be removed by using simulators or emulators.

For example, we might want to implement the communication protocol without having a working radio only if there is a way to test the protocol against the agent running on the gateway by using a simulated radio channel on the gateway itself. Keeping the modules self-contained and with a minimal set of API calls exposed to the outside makes it easier to detach the single modules to run and test them on different architectures, and under a controlled environment, before integrating them into the target system.

Prototyping

As it is part of the specifications, we know that we should prioritize the activities related to the radio communication to allow the hardware team to progress on the design, so in this case, the first prototype must do the following:

1. Boot a minimal system on the target (empty main loop).
2. Set up serial port 0 for logging.
3. Set up an SPI port to communicate to the radio chip.
4. Write the radio driver.
5. Set up the timer.
6. Write the main application to test the radio channel (sending raw packets at regular intervals).

This first prototype will already start to look like the final device, even if it does not yet know how to communicate with the sensor. Some test cases can already be implemented to run on a mock gateway, checking that messages are received and valid.

Moving ahead to the next prototype definition, we can start to add a few additional features. Real sensor readings are not necessary to progress on the protocol with the gateway, as it is possible to use made-up, synthetic test values that reproduce a specific behavior instead. This allows us to progress on other tasks when the real hardware is not available.

Whether the development team is adopting pure agile software development or is working with a different methodology, fast prototyping in an embedded development environment allows responding faster to the uncertainties on the path, which often depend on the behavior of the hardware and the actions that need to be taken in the software.

Providing workable intermediate deliverables is a common practice in embedded development teams, which directly derives from agile methodologies. Agile software development foresees the delivery of working software regularly and within short intervals of time. Like in the preceding example, an intermediate prototype does not have to implement all the logic of the final software image but instead must be used to prove concepts, make measurements, or provide examples on top of a reduced part of the system.

Refactoring

Too often considered a drastic remedy for a failure, refactoring is actually a healthy practice that improves the software while the system takes its final shape, and the support for software components and peripherals evolves over time.

Refactoring works better if all the tests are up and running on the old code. Unit tests should be adapted to the new function signatures while redesigning the module internals. On the other hand, existing functional tests for the module being refactored should not change if the API of the module stays unchanged and will provide continuous feedback about the status and the accuracy of the process as long as the interface toward other modules remains the same.

Smaller portions of the code base are exponentially easier to refactor than larger ones, which gives us yet another reason to keep each module small and dedicated to a specific function on the system. Progressing through intermediate deliverable prototypes implies constant alterations in the application code, which should require less effort when the subsystems are designed to be independent of each other and from the application code itself.

API and documentation

We all know that a book should not be judged by its cover. However, a system can often be judged by its API, which may reveal many aspects of the internal implementation and the design choices of the system architects. A clear, readable, and easy-to-understand API is one of the most important features of an embedded system. Application developers expect to understand how to access functionalities quickly and to use the system in the most efficient way possible. The API represents the contract between the system and the applications, and for this reason, it must be designed beforehand and modified as little as possible, if at all, while the development moves towards the final delivery.

Some interfaces in the API may describe complex subsystems and abstract more elaborate characteristics, so it is always a good idea to provide adequate documentation to help application developers move around and exploit all the system capabilities. There are different ways to provide documentation along with the code, either distributing user manuals in the repository as separate files or including the explanation of the different interfaces directly in the code.

The amount of comments in the code is not an indicator of quality. Comments tend to age whenever the code they refer to gets modified because of the possibility that the developer forgets to update the comment to match the new behavior in the code. Moreover, not all code needs to be commented; good habits, such as keeping functions short and low in complexity or using expressive symbol names, would make code comments redundant in most cases, as the code can explain itself.

There are exceptions for lines of code that contain complex calculations, bit shifting, elaborate conditions, or side effects that are not easy to spot when reading the code for the first time. Some portions of code may also require a description at the beginning, for example, those functions with multiple return values and specific error handling. Switch/case statements not containing the break instruction between two cases must always have a comment to indicate that the fall-through is intended and not a mistake.

They should also possibly explain why some actions are grouped between two or more cases. Adding superfluous comments that do not provide any valuable explanation of the code only contributes to making the code harder to read.

On the other hand, describing the behavior of a module with a separate editor and tools requires dedication, as all the documentation must be updated every time there are significant changes in the code, and the developers are asked to switch the focus away from the actual code.

Usually, the important part to document is the description of the contract mentioned previously, enumerating and explaining the functions and the variables that the applications and the other components involved can access at runtime. Since these declarations can be grouped within header files, it is possible to describe the entire contract by adding extended comments on top of the declaration of each exported symbol.

Software tools exist that convert these comments into formatted documentation. A popular example is Doxygen, a free and open source document-generation tool that parses comments matching a specific syntax in the whole code base to produce hypertexts, structured PDF manuals, and many other formats. If the documentation is in the code base, updating and keeping track of its results is easier and less invasive for the developers’ workflow. Integrating the generation of the documentation on the automation server can provide a freshly generated copy of the manuals for all the APIs at every commit on the master branch.

Summary

The methodologies that have been proposed are meant as an example of reference patterns used to design and manage the development of embedded projects. While it is possible that some of the patterns described may not apply to all projects, the goal of this chapter is to encourage embedded architects to look for improvements in the process that may result in a more efficient and less expensive software life cycle. Finally, we analyzed the possibility of increasing security by adding appropriate processes and components when required by the use case.

In the next chapter, we shall analyze what happens at boot time inside the embedded system, and how to prepare a bootable application using a simple, bare-metal, main-loop approach.

4

The Boot-Up Procedure

Now that the mechanisms, tools, and methodologies are in place, it is finally time to start looking at the procedures required to run the software on the target. Booting up an embedded system is a process that often requires knowledge of the specific system and the mechanisms in play. Depending on the target, there are a few indications we need to look for in the manual to find out what the system expects from the developer to successfully boot executables from the flash memory. This chapter will focus on the description of the boot process, with emphasis on the case of the Cortex-M microcontroller, which we decided to use as a reference platform. In particular, we will cover the following topics:

• The interrupt vector table
• Memory layout
• Building and running the boot code
• Multiple boot stages

By the end of this chapter, you will have an overview of main-loop embedded development.

Technical requirements

You can find the code files for this chapter on GitHub at https://github.com/PacktPublishing/Embedded-Systems-Architecture-Second-Edition/tree/main/Chapter4.

The interrupt vector table

The interrupt vector table, often abbreviated to IVT or simply IV, is an array of pointers to functions associated by the CPU to handle specific exceptions, such as faults, system service requests from the application, and interrupt requests from peripherals. The IVT is usually located at the beginning of the binary image and thus is stored starting from the lowest address in the flash memory.

An interrupt request from a hardware component or peripheral will force the CPU to abruptly suspend the execution and execute the function at the associated position in the vector. For this reason, these functions are called interrupt service routines (or simply ISRs). Runtime exceptions and faults can be handled in the same way as hardware interrupts, so special service routines are associated with internal CPU triggers through the same table.

The order of the ISRs enumerated in the vector, and their exact positions depend on the CPU architecture, the microcontroller model, and the peripherals supported. Each interrupt line corresponds to a predefined interrupt number and, depending on the microcontroller features, may be assigned a priority.

In a Cortex-M microcontroller, the first 16 positions in memory are reserved for storing the pointers to system handlers, which are architecture-dependent, and associated to different types of CPU runtime exceptions. The lowest address is used to store the initial value of the stack pointer, and the next 15 positions are reserved for system services and fault handlers. However, some of these positions are reserved and not connected to any event. The system exceptions that can be handled using separate service routines in a Cortex-M CPU are as follows:

• Reset
• Non-Maskable Interrupt (NMI)
• Hard fault
• Memory exception
• Bus fault
• Usage fault
• Supervisor call
• Debug monitor event
• PendSV call
• System tick

The order of the hardware interrupts, starting from position 16, depends on the microcontroller configuration and, thus, on the specific silicon model, as the interrupt configuration refers to specific components, interfaces, and external peripheral activities.

A fully populated vector of external interrupt handlers for STM32F407 and LM3S targets can be found in this book’s code repository.

Startup code

In order to boot a workable system, we need to define the interrupt vector and associate pointers with defined functions. A typical startup code file for our reference platform places the interrupt vector in a dedicated section using the GCC section attribute. As the section will be put at the beginning of the image, we must define our interrupt vector starting with the reserved space for the initial stack pointer, followed by the system exception handlers.

The zeros correspond to the positions of the reserved/unused slots:

__attribute__ ((section(".isr_vector")))
void (* const IV[])(void) =
{
  (void (*)(void))(END_STACK),
  isr_reset,
  isr_nmi,
  isr_hard_fault,
  isr_mem_fault,
  isr_bus_fault,
  isr_usage_fault,
  0, 0, 0, 0,
  isr_svc,
  isr_dbgmon,
  0,
  isr_pendsv,
  isr_systick,

From this position on, we define the interrupt lines for the external peripherals as follows:

  isr_uart0,
  isr_ethernet,
  /* … many more external interrupts follow */
};

The startup code must also include the implementation of every symbol referenced in the array. The handler can be defined as void procedures with no arguments, in the same format as the signature of the IV:

void isr_bus_fault(void) {
  /* Bus error. Panic! */
  while(1);
}

The interrupt handler in this example never returns, as a result of an unrecoverable bus error, and hangs the system forever. Empty interrupt handlers can be associated to both system and external interrupts using weak symbols that can be overridden in the device driver modules by simply defining them again in the relevant code section.

Reset handler

When the microcontroller is powered on, it starts the execution from the reset handler. This is a special ISR that does not return but rather performs initialization of the .data and .bss sections, and then calls the entry point of the application. The initialization of the .data and .bss sections consists of copying the initial value of the variables in the .data section in flash onto the actual section in RAM where variables are accessed at runtime and filling the .bss section in RAM with zeros so that the initial value of static symbols is guaranteed to be zero as per C convention.

The source and destination addresses of the .data and .bss sections in RAM are computed by the linker when generating the binary image and exported as pointers using the linker script. The implementation of isr_reset may look similar to the following:

void isr_reset(void)
{
  unsigned int *src, *dst;
  src = (unsigned int *) &_stored_data;
  dst = (unsigned int *) &_start_data;
  while (dst != (unsigned int *)&_end_data) {
    *dst = *src;
    dst++;
    src++;
  }
  dst = &_start_bss;
  while (dst != (unsigned int *)&_end_bss) {
    *dst = 0;
    dst++;
  }
  main();
}

Once the variables in the .bss and .data sections have been initialized, it is finally possible to call the main function, which is the entry point of the application. The application code ensures that main never returns by implementing an infinite loop.

Allocating the stack

In order to comply with the application binary interface (ABI) of the CPU, it is required to assign space in memory for the execution stack. This can be done in different ways, but usually, it is preferable to mark the end of the stack space in the linker script and associate the stack space to a specific area in RAM, not in use by any section.

The address obtained through the END_STACK symbol, exported by the linker script, points to the end of an unused area in RAM. As mentioned earlier, its value must be stored at the beginning of the vector table, at address 0 in our case, just before the IV. The address of the end of the stack has to be constant and cannot be calculated at runtime because the IV content is stored in the flash memory and thus cannot be modified later on.

Properly sizing the execution stack in memory is a delicate task that includes the assessment of the whole code base, keeping in mind stack usage from local variables and the depth of the call trace at any time during the execution. The analysis of all the factors related to stack usage and troubleshooting will be part of a wider topic that is covered in the next chapter. Our simple startup code provided here has a stack size that is big enough to contain the local variables and the function call stack, as it is mapped by the linker script as far as possible from the .bss and .data sections. Further aspects of the placement of the stack are considered in Chapter 5, Memory Management.

Fault handlers

Fault-related events are triggered by the CPU in the case of execution errors or policy violations. The CPU is able to detect a number of runtime errors, such as the following:

• Attempting to execute code outside the memory areas marked as executable
• Fetching data or the next instruction to execute from an invalid location
• Illegal loading or storing using an unaligned address
• Division by zero
• Trying to access unavailable coprocessor functionalities
• Attempting to read/write/execute outside the memory areas allowed for the current running mode

Some core microcontrollers support different types of exceptions depending on the type of error. The Cortex-M3/M4 can distinguish between bus errors, usage faults, memory access violations, and generic faults, triggering the related exception. In other, smaller systems, fewer details are available on the type of runtime error.

Very often, a fault will make the system unusable or unable to continue the execution due to the CPU register values or the stack being corrupted. In some cases, even placing a breakpoint inside the exception handler is not sufficient to detect the cause of the problem, making debugging harder. Some CPUs support extended information on the cause of the fault, which is available through memory-mapped registers after the exception occurs. In the case of the Cortex-M3/M4, this information is available through the Configurable Fault Status Register (CFSR), which is mapped at address 0xE000ED28 on all Cortex-M3/M4 CPUs.

Memory violations may be non-fatal if the corresponding exception handler implements some kind of recovery strategy and can be useful to detect and react to the fault at runtime, which is especially useful in multithreaded environments, as we will see in more detail in Chapter 9, Distributed Systems and IoT Architecture.

Memory layout

The linker script, as we already know, contains the instructions for the linker on how to assemble the components of an embedded system. More specifically, it describes the sections mapped in memory and how they are deployed into the flash and the RAM of the target, as in the example provided in Chapter 2, Work Environment and Workflow Optimization.

In most embedded devices, and in particular our reference platform, the .text output section in the linker script, which contains all the executable code, should also include the special input section dedicated to storing the IV at the very beginning of the executable image.

We integrate the linker script by adding the .isr_vector section at the beginning of the .text output section before the rest of the code:

.text :
{
  *(.isr_vector)
  *(.text*)
  *(.rodata*)
} > FLASH

Defining a read-only area in flash, which is dedicated to the vector table, is the only strict requirement for our system to boot up properly, as the address of the isr_reset function is retrieved by the CPU at boot time from the 0x04 address in memory.

Right after the definition for the text and read-only areas in flash, the linker script should export the value of the current address, which is the beginning of the .data output section stored in flash. This section contains the initial value of all the global and static variables that have been initialized in the code. In the example linker script, the beginning of the .data section is marked by the _stored_data linker script variable, as follows:

_stored_data = .;

The data section will eventually be mapped in RAM, but its initialization is done manually in the isr_reset function by copying the content from flash to the actual region designated to the .data section in RAM. The linker script provides a mechanism to separate the Virtual Memory Address (VMA) and the Load Memory Address (LMA) for a section, using the AT keyword in the definition of the section. If no AT keyword is specified, the LMA is, by default, set to the same address as the VMA. In our case, the VMA of the .data input section is in RAM and exported using the _start_data pointer, which will be used by isr_vector as the destination address when copying the values of the symbols stored from flash. The LMA of .data, though, is located in the flash memory, so we set the LMA address to the _stored_data pointer in flash, while defining the .data output section:

.data : AT (_stored_data)
{
  _start_data = .;
  *(.data*)
  . = ALIGN(4);
  _end_data = .;
} > RAM

For .bss, there is no LMA, as no data is stored in the image for this section. When including the .bss output section, its VMA will automatically be set to the end of the .data output section:

.bss :
{
  _start_bss = .;
  *(.bss*)
  . = ALIGN(4);
  _end_bss = .;
  _end = .;
} > RAM

Finally, in this design, the linker is expected to provide the initial value for the execution stack. Using the highest address in memory is a common choice for a single-threaded application, even though, as discussed in the next chapter, this may cause problems in the case of stack overflow. For this example, however, this is an acceptable solution, and we define the END_STACK symbol by adding the following line to the linker script:

END_STACK = ORIGIN(RAM) + LENGTH(RAM);

To better understand where each symbol will be placed in memory, variable definitions can be added to the startup file in different places within the code. This way, we can check the locations where the variables are stored in memory when running the executable in the debugger for the first time. Supposing that we have variables stored in both the .data and .bss output sections, the memory layout for the example startup code may look like the following:

Figure 4.1 – Memory layout in the example startup code

When the executable is linked, the symbols are automatically set at compile time to indicate the beginning and the end of each section in memory. In our case, variables indicating the beginning and the end of each section are automatically assigned to the right value, depending on the size of the sections that the linker will include when creating the executable. Since the size of each section is known at compile time, the linker is able to identify those situations where the .text and .data sections do not fit into the flash, and a linker error is generated at the end of the build. Creating a map file is useful for checking the size and the location of each symbol. In our boot-up example code, here is how the .text section appears within the map file:

.text 0x0000000000000000 0x168
0x0000000000000000 _start_text = .
*(.isr_vector)
.isr_vector 0x0000000000000000 0xf0 startup.o
0x0000000000000000 IV
*(.text*)
.text 0x00000000000000f0 0x78 startup.o
0x00000000000000f0 isr_reset
0x0000000000000134 isr_fault
0x000000000000013a isr_empty
0x0000000000000146 main

Similarly, we can find the boundaries of each section, exported by the linker script at compile time:

0x0000000000000000 _start_text = .
0x0000000000000168 _end_text = .
0x0000000020000000 _start_data = .
0x0000000020000004 _end_data = .
0x0000000020000004 _start_bss = .
0x0000000020000328 _end_bss = .
0x0000000020000328 _end = .

The .rodata input section, which is empty in this minimalist example, is mapped in the flash memory area, in between .text and the data LMA. This is reserved for constant symbols because constants do not have to be mapped in RAM. It is advisable to enforce the const C modifier when defining constant symbols because RAM is often our most precious resource, and in some cases, even sparing a few bytes of writable memory by moving constant symbols to the flash can make a difference in the project development, as flash memory is usually much bigger, and its usage can be easily determined at linking time.

Building and running the boot code

The example provided here is one of the simplest executable images that can be run on the target. To assemble, compile, and link everything together, we can use a simple makefile that automates all the steps and allows us to focus on our software life cycle.

When the image is ready, we can transfer it to the real target or alternatively, run it using an emulator.

The makefile

A very basic makefile to build our startup application describes the final target (image.bin) and the intermediate steps required to build it. Makefile syntax is, in general, very vast, and covering all the functions provided by Make is outside the scope of this book. However, the few concepts explained here should be sufficient to get up and running on automating the build process.

Defining the targets for our makefile, in this case, is quite simple. The startup.c source file, containing the IV, some exception handlers, and the main and the global variables we used in the example, can be compiled and assembled into a startup.o object file. The linker uses the indications provided in the target.ld linker script to deploy the symbols in the correct sections, producing the .elf executable image.

Finally, objcopy is used to transform the .elf executable into a binary image, which can be transferred to the target or run using QEMU:

Figure 4.2 – Build steps and dependencies

The makefile should contain a few configuration variables to describe the toolchain. The = assignment operator allows you to set values for the variables when invoking the make command. Some of these variables are implicitly used as default during compilation and linking. It is common practice to define the toolchain prefix using the CROSS_COMPILE variable and use that as a prefix for the tools involved in the build process:

CROSS_COMPILE=arm-none-eabi-
CC=$(CROSS_COMPILE)gcc
LD=$(CROSS_COMPILE)ld
OBJCOPY=$(CROSS_COMPILE)objcopy

Changing the default cross compiler for this project can be done by running make and assigning a different value to the CROSS_COMPILE environment variable. All the names of the tools are prefixed by the CROSS_COMPILE variable expansion so that the build steps will use the components from the given toolchain. In the same way, we can define our default flags for the compiler and the linker:

CFLAGS=-mcpu=cortex-m3 -mthumb -g -ggdb -Wall -Wno-main
LDFLAGS=-T target.ld -gc-sections -nostdlib -Map=image.map

When invoked with no arguments, Make builds the first target defined in the image.bin makefile. A new target for image.bin can be defined as follows:

image.bin: image.elf
 $(OBJCOPY) -O binary $^ $@

The $@ and $^ variables will be replaced in the recipe with the target and the list of dependencies, respectively. This means that, in the example, the makefile will process the recipe as follows:

arm-none-eabi-objcopy -O binary image.elf image.bin

This is the command we need to produce a raw binary image from the .elf executable.

Similarly, we can define the recipe for image.elf, which is the linking step, depending on the startup.o compiled object file, and the linker script:

image.elf: startup.o target.ld
 $(LD) $(LDFLAGS) startup.o -o $@

In this case, we are not going to use the $^ variable for the list of dependencies, as the recipe includes the linker script in the linker command line using LDFLAGS. The recipe for the linking step will be expanded by main as follows:

arm-none-eabi-ld -T target.ld -gc-sections -nostdlib -Map=image.map startup.o -o image.elf

Using -nostdlib ensures that no default C libraries are linked automatically to the project, among those available in the toolchain, that would, by default, be linked in to produce the executables. This ensures that no symbols are automatically pulled.

The last step for resolving dependencies is compiling the source code into the object file. This is done in a makefile implicit recipe that eventually gets translated to the following when using the project default values:

arm-none-eabi-gcc -c -o startup.o startup.c -mcpu=cortex-m3 -mthumb -g -ggdb -Wall -Wno-main

Using the -mcpu=cortex-m3 flag ensures that the code produced is compatible with Cortex-M targets from Cortex-M3 onward. The same binary can, in fact, eventually be run on any Cortex-M3, M4, or M7 target, and it is generic until we do not decide to use any CPU-specific feature, or define hardware interrupt handlers, as the order of those depends on the specific microcontroller.

By defining a clean target, at any point in time, it is possible to start over from a clean slate, by removing the intermediate targets and the final image and running make again. The clean target is also often included in the same makefile. In our example, it looks as follows:

clean:
 rm -f image.bin image.elf *.o image.map

The clean target usually has no dependencies. Running make clean removes all the intermediate and final targets as instructed in the recipe, leaving the sources and the linker script untouched.

Running the application

Once the image is built, we can run it on a real target or using qemu-system-arm, as explained in Chapter 2, Work Environment and Workflow Optimization. Since the application will produce no output while running on the emulator, to investigate more about the actual behavior of the software, we need to attach a debugger to it. When running the emulator, qemu-system-arm must be invoked with the -S option, meaning stop, so that it will not start the execution until the debugger is connected. Since the CFLAGS variable in the previous step contains the -g option, all the symbol names will be kept in the .elf executable so that the debugger can follow the execution through the code line by line, placing breakpoints and checking the values for the variables.

Following the procedures step by step and comparing addresses and values with those in the .map files can be helpful in understanding what is happening and how the context changes through the entire boot sequence.

Multiple boot stages

Booting a target through a bootloader is useful in several cases. In a real-life scenario, being able to update the running software on devices in a remote location means that developers are able to fix bugs and introduce new features after the first version of the embedded system has been deployed.

This represents a huge advantage for maintenance when a bug is discovered in the field, or when the software has to be re-engineered to adapt to changes in requirements. Bootloaders may implement automatic remote upgrades and other useful features, such as the following:

• Loading of the application image from an external storage
• Verification of the integrity of the application image before boot
• Failover mechanisms in case of a corrupted application

Multiple bootloaders can be chained to perform a multiple-stage boot sequence. This allows you to have separate software images for the multiple boot stages, which can be uploaded to the flash independently. A first-stage boot, when present, is usually very simple and used to simply select the entry point for the next stage. However, in some cases, early stages benefit from slightly more complex designs to implement software upgrade mechanisms or other features. The example proposed here shows the separation between two boot stages, achieved using the functionalities available in many Cortex-M processors. The only purpose of this simple bootloader is to initialize the system for booting the application in the next stage.

Bootloader

The first-stage bootloader starts up as a normal standalone application. Its IV must be located at the beginning of the flash, and the reset handler initializes the associated .data and .bss memory sections, like in a normal single-stage boot. A partition at the beginning of the flash should be reserved for the .text and .data bootloader sections. To do so, the linker script for the bootloader will only include the beginning of the flash memory, and that of the application will have an offset of the same size.

The bootloader and the application will, in fact, be built into two separate binaries. This way, the two linker scripts can have the same name for sections, and differ only by the description of the FLASH partition in the linker memory. Nevertheless, the method suggested next is only one of the possible configurations: a more complex setup may benefit from exporting the full geometry using the start addresses and sizes of all the partitions.

If we want to reserve 4 KB for the bootloader partition, we can hardcode the FLASH area in the bootloader linker script as follows:

FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x00001000

Similarly, the linker script of the application has an offset in the origin, hardcoded to the size of the bootloader, so that the .text output section of the application always starts at the 0x1000 address. From the application point of view, the whole FLASH area starts from the 0x00001000 address:

FLASH (rx) : ORIGIN = 0x00001000, LENGTH = 0x0003F000

The geometry of the flash, in this case, would be the following:

Figure 4.3 – Layout of the flash content, showing the sections of both the bootloader and the application

Bootloader and Application run separate code and can define their own IV based on the handler that will be used in the respective stage. The simplest example of a working bootloader can be realized by hardcoding the address of the application and jumping to the entry point, being the reset handler in the IV of the application stored with offset 4 inside the vector table.

The application may enforce its own memory layout. At startup, it will be able to initialize the new .data and .bss sections according to the new geometry and even define a new initial stack pointer and IV. The bootloader can obtain these two pointers by reading the first two words of the IV stored at address 0x1000:

uint32_t app_end_stack = (*((uint32_t *)(APP_OFFSET)));
void (* app_entry)(void);
app_entry = (void *)(*((uint32_t *)(APP_OFFSET + 4)));

Before jumping to the entry point of the application, we want to reset the main execution stack pointer to the end address of the stack. Since MSP is a special-purpose CPU register in the ARMv7-M architecture, it can only be written using the assembly instruction move special from register (msr). The following code is inlined in the bootloader to set the correct application stack pointer to the value stored in flash at the beginning of the application image:

asm volatile("msr msp, %0" ::"r"(app_end_stack));

In Cortex-M3 and other, more powerful, 32-bit Cortex-M CPUs, a control register is present within the system control block area, which can be used to specify an offset for the vector table at runtime. This is the Vector Table Offset Register (VTOR), which is located at address 0xE000ED08. Writing the application offset to this register means that, from that moment, the new IV is in place, and the interrupt handlers defined in the application will be executed upon exceptions:

uint32_t * VTOR = (uint32_t *)0xE000ED08;
*VTOR = (uint32_t *)(APP_OFFSET);

When this mechanism is not available, like in Cortex-M0 microcontrollers, which do not have a VTOR, the application will still share the interrupt vector with the bootloader after it is started. To provide a different set of interrupt handlers, the relevant function pointers can be stored in a different area of the flash, and the bootloader can check whether the application had been started or not at every interrupt, and in case it was, call the respective handler from the table in the application space.

When handling pointers to interrupt handlers and other exception routines, it is important to consider that an exception can occur at any time while running the code, especially if the bootloader has enabled peripherals or activated timers in the CPU. To prevent unpredictable jumps to interrupt routine, it is advisable to disable all the interrupts while the pointers are being updated.

The instruction set provides mechanisms to temporarily mask all the interrupts. While running with the interrupt globally disabled, the execution cannot be interrupted by any exception, excluding NMI. In Cortex-M, interrupts can be temporarily disabled by using the cpsid i assembly statement:

asm volatile ("cpsid i");

To enable the interrupt again, the cpsie i instruction is used:

asm volatile ("cpsie i");

Running code with interrupts disabled should be done as much as strictly necessary, and not done only in special cases where other solutions are not available because it impacts the latency of the entire system. In this special case, it is used to ensure that no service routines are invoked while the IV is being relocated.

The last action performed by the bootloader in its short life is a direct jump to the reset handler in the application IV. Since the function will never return, and a brand-new stack space has been just allocated, we force an unconditional jump by setting the value CPU program counter register to start executing from the address of app_entry, which is pointed to by isr_reset:

asm volatile("mov pc, %0" :: "r"(app_entry));

In our example, this function will never return, since we replaced the execution stack pointer value. This is compatible with the behavior foreseen by the reset handler, which will, in turn, jump to the main function in the application.

Building the image

Since the two executables will be built in separate .elf files, there are mechanisms to join the content of the two partitions together into a single image, to upload to the target, or to use in the emulator. The bootloader partition can be filled with zeros up to its size by using the --pad-to option of objcopy when converting the .elf executable into the binary image. Wearing the flash can be reduced by using the 0xFF value to fill the padding area, which can be obtained by passing the --gap- option fill=0xFF. The resultant image bootloader.bin will be exactly 4096 bytes so that the application image can be concatenated at the end of it. The steps to compose an image containing the two partitions are the following:

$ arm-none-eabi-objcopy -O binary --pad-to=4096 --gap-fill=0xFF bootloader.elf bootloader.bin
$ arm-none-eabi-objcopy -O binary app.elf app.bin
$ cat bootloader.bin app.bin > image.bin

Looking at the resultant image.bin file with a hexadecimal editor, it should be possible to identify the end of the bootloader within the first partition by recognizing the zero pattern that is used by objdump as padding, and the application code starting at address 0x1000.

By aligning the application offset to the start of a physical page in flash instead, it is even possible to upload the two images in separate steps, allowing you, for instance, to upgrade the application code, leaving the bootloader partition untouched.

Debugging a multi-stage system

The separation between two or more stages implies that the symbols of the two executables are linked into different .elf files. Debugging using both sets of symbols is still possible, but the symbols from both .elf files must be loaded in the debugger in two steps. When the debugger is executed using the symbols from the bootloader, by adding the bootloader.elf file as an argument, or using the file command from the GDB command line, the symbols of the bootloader are loaded in the symbol table for the debugging session. To add the symbols from the application .elf file, we can add the corresponding .elf at a later stage using add-symbol-file.

The add-symbol-file directive, unlike file, ensures that the symbols of a second executable are loaded without overwriting the ones previously loaded and allows you to specify the address where the .text section starts. In the system composed in this example, there is no clash between the two sets of symbols, as the two partitions do not share any area on the flash. The debugger can continue the execution normally and still have all the symbols available after the bootloader jumps to the application entry point:

> add-symbol-file app.elf
add symbol table from file "app.elf"(y or n) y
Reading symbols from app.elf...done.

Sharing the same names for sections and symbols between the two executables is legal, as the two executables are self-contained and not linked together. The debugger is aware of duplicate names when we refer to a symbol by its name during debugging. For example, if we place a breakpoint on main and we have correctly loaded the symbols from both executables, the breakpoint will be set on both locations:

> b main
Breakpoint 1 at 0x14e: main. (2 locations)
> info b
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x0000014e in main at startup_bl.c:53
1.2 y 0x00001158 in main at startup.c:53

Separate boot stages are completely isolated from each other and do not share any executable code. For this reason, software distributed with different licenses, even if not compatible with each other, can run in separate boot stages. As seen in the example, the two software images can use the same symbol names without creating conflicts, as they would have been running on two separate systems.

In some cases, however, multiple boot stages may have functionalities in common that can be implemented using the same library. Unfortunately, there is no simple way to access the symbols of the library from separate software images. The mechanism described in the next example provides access to shared libraries between the two stages by storing the symbols needed only once in the flash.

Shared libraries

Suppose that there is a small library providing general-purpose utilities or device drivers, which is in use by both the bootloader and the application. Even when the footprint is small, it is preferable not to have duplicate definitions of the same functions in the flash memory. The library can instead be linked in a dedicated section of the bootloader and referred to in a later stage. In our preceding two-stage example, we can safely place the API function pointers in an array starting at address 0x400, which is past the end of the interrupt vector we are currently using. In a real project, the offset must be high enough to be after the actual vector table in memory. The .utils input section is placed in the linker script in between the vector table and the start of .text in the bootloader:

.text :
{
  _start_text = .;
  KEEP(*(.isr_vector))
  . = 0x400;
  KEEP(*(.utils))
  *(.text*)
  *(.rodata*)
  . = ALIGN(4);
  _end_text = .;
} > FLASH

The actual function definitions can be placed in a different source file and linked in the bootloader. What is actually in the .utils section is a table containing the pointers to the actual address of the functions inside the .text bootloader output section:

__attribute__((section(".utils"),used))
 static void *utils_interface[4] = {
   (void *)(utils_open),
   (void *)(utils_write),
   (void *)(utils_read),
   (void *)(utils_close)
};

The layout of the bootloader now has this extra .utils section, aligned at address 0x400, containing a table with the pointers to the library functions that are meant to be exported for use from other stages:

Figure 4.4 – Bootloader partition with the .utils section

The application expects to find the function table at the given address:

static void **utils_interface = (void**)(0x00000400);

The address of the single functions that have been stored in the bootloader is now available, but there is no information about the signature of these functions. For this reason, the application can only access the API properly if the pointers are converted to match the expected function signature. An inline wrapper can then be provided so that the application code can access the function directly:

static inline int utils_read(void *buf, int size) {
  int (*do_read)(void*, int) = (int (*)(void*,int))
    (utils_interface[2]);
  return do_read(buf, size);
}

In this case, the contract is implicitly shared between the two modules, and the correspondence between the function signatures is not checked at compile time, nor is the validity of the function pointer stored in flash. On the other hand, it is a valid approach to avoid binary code duplication and might be an effective way to reduce flash usage by sharing symbols across separate contexts.

Remote firmware updates

One of the reasons to include a bootloader in an embedded system design is often to provide a mechanism to update the running application from a remote location. As mentioned in the previous chapter, a reliable update mechanism is often a critical requirement for vulnerability management. On rich embedded systems running Linux, bootloaders are often equipped with their own TCP/IP stacks, network device drivers, and protocol-specific implementations to transfer kernel and filesystem updates autonomously. On smaller embedded systems, it is often convenient to assign this task to the application, which is in most cases already using similar communication channels for other functional purposes. Once the new firmware has been downloaded and stored in any non-volatile memory support (for example, in a partition at the end of the flash memory), a bootloader could implement a mechanism to install the received update by overwriting the previous firmware in the Application partition.

Secure boot

Many projects require a mechanism to prevent the execution of unauthorized or altered firmware that could have been compromised intentionally by an attacker in an attempt to take control of the system. This is a task for secure bootloaders, which use cryptography to verify the authenticity of a signature calculated on the content of the firmware image on board. Secure bootloaders implementing such mechanisms rely on a trust anchor to store a public key and require the use of a manifest that must be attached to the firmware image file. The manifest contains the signature that has been created by the owner of the private key associated with the public key stored in the device. Cryptographic signature verification is a very effective method to prevent unauthorized firmware updates, both from remote locations and from physical attacks.

Implementing a secure bootloader from scratch is a considerable amount of work. A few open source projects provide a mechanism to sign and verify images using cryptography algorithms. wolfBoot is a secure bootloader providing integrity and authenticity checks of the current firmware and the candidates for update installations. It provides a fail-safe mechanism to swap the two firmware partitions’ content during the update installation, to provide a backup in case of failed execution of the newly updated image. The bootloader comes with tools to generate the signature and attach the manifest to the file to be transferred to the device, and a wide range of configurable options, ciphers, and features.

Summary

Understanding the boot procedure is a key step toward the development of an embedded system. We have seen how to boot straight into the bare-metal application, and we have examined the structures involved in a multi-stage system boot, such as separate linker scripts with different entry points, the relocation of IVs via CPU registers, and shared code sections across stages.

In the next chapter, we will explore mechanisms and approaches for memory management that represent the most important factor to take into account while developing safe and reliable embedded systems.

5

Memory Management

Handling memory is one of the most important tasks for an embedded system programmer, and surely the most important to take into account in every phase of the development of a system. This chapter is about the models commonly used to manage memory in an embedded system, the geometry and the mapping of the memory, and how to prevent issues that could compromise the stability and safety of the software running on the target.

This chapter is divided into four parts:

• Memory mapping
• The execution stack
• Heap management
• The memory protection unit

By the end of this chapter, you will have an in-depth knowledge of how to manage the memory in an embedded system.

Technical requirements

You can find the code files for this chapter on GitHub at https://github.com/PacktPublishing/Embedded-Systems-Architecture-Second-Edition/tree/main/Chapter5/memory.

Memory mapping

Application software usually benefits from a number of abstractions available in the environment for the handling of memory. In modern operating systems on personal computers, each process can access its own memory space, which can also be relocated by remapping memory blocks to virtual memory addresses. Moreover, dynamic memory allocations are possible through virtual memory pools provided by the kernel. Embedded devices do not rely on these mechanisms, as there is no way to assign virtual addresses to physical memory locations. In all contexts and running modes, all the symbols can be accessed only by pointing at physical addresses.

As we have seen in the previous chapter, booting a bare-metal embedded application requires defining the sections at compile time within the assigned regions in the available address space, using the linker script. In order to properly configure the memory sections in our embedded software, it is important to analyze the properties of the various regions and the techniques that we can use to organize and manage the memory areas.

Memory model and address space

The total amount of available addresses depends on the size of memory pointers. 32-bit machines can reference a contiguous memory space of 4 GB, which is segmented to host all the memory-mapped devices in a system. This may include the following:

• Internal RAM
• Flash memory
• System control registers
• Components internal to the microcontroller
• An external peripheral bus
• Additional external RAM

Every region has a fixed physical address that may depend on the characteristics of the platform. All the locations are hardcoded, and some of them are platform-specific.

In the ARM Cortex-M, the total addressable space is divided into six macro-regions. Depending on their purpose, the regions have different permissions so that there are areas of memory that can only be accessible for read operations at runtime, or that are not allowed to execute in place. These constraints are implemented in hardware but might be configurable at runtime on microcontrollers that include an MPU:

Figure 5.1 – The ARM Cortex-M address space

In general, only small sections (that are the same size as physical components) are mapped within these regions. Trying to access memory that is not mapped to any hardware triggers an exception in the CPU. When approaching a target platform, it is important to know the locations and the sizes of the memory sections corresponding to the hardware on board, in order to properly describe the geometry of the available address space in the linker script and in the source code.

The code region

The lowest 512 MB of the addressing space in a Cortex-M microcontroller is reserved for executable code. Targets that support XIP always map the flash memory within this area, and the memory is generally not writable at runtime. In our previous examples, the .text and .rodata sections are mapped within this region, as they remain constant during the execution of the software. Additionally, the initial values of all non-zero defined symbols are placed in this area and need to be explicitly copied and re-mapped to a writable segment in order to modify their value at runtime. As we already know, the interrupt vector table (IVT) is usually located at the beginning of the mapped section. Multiple flash memory banks may be mapped into the code region. The regions associated with physical devices must be known in advance and are dependent on the hardware design. Many microcontrollers map the code region at address 0x00000000, while others choose a different starting address (for example, 0x10000000 or 0x08000000). STM32F4 FLASH memory is mapped at 0x08000000 and provides an alias so that the same memory can be accessed at runtime, starting at address 0x00000000 as well.

Note

When the flash memory address starts at address 0, NULL pointers can be de-referenced and will point to the beginning of the code region, which is normally accessible for reading. While this technically violates the C standard, it is a common practice within embedded C code to read from address 0x00000000in these cases – for example, to read the initial stack pointer in the IVT on the ARM.

The RAM regions

Internal RAM banks are mapped to addresses in the second 512 MB block, starting at address 0x20000000. External memory banks may be mapped anywhere in the 1 GB region, starting at address 0x60000000. Depending on the geometry of the internal SRAM inside the Cortex-M microcontroller, or the displacement of external memory banks, actually accessible memory areas can be mapped in non-contiguous, different parts of the memory within the allowed range. Memory management must take into account discontinuity in the physical mapping and refer to each section separately. The STM32F407 MPU, for example, has two non-contiguously mapped blocks of internal SRAM:

• 128 KB of SRAM at address 0x20000000 (in two contiguous blocks of 112 KB and 16 KB)
• A separate bank of 64 KB Core-Coupled Memory (CCM), mapped at address 0x10000000

This second memory is tightly coupled to the CPU and optimized for time-critical operations, which allows for zero wait state access from the CPU itself.

In this case, we may reference the two blocks as two separate areas in the linker script:

flash (rx) : ORIGIN = 0x08000000, LENGTH = 256K
SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
CCMSRAM(rwx) : ORIGIN = 0x10000000, LENGTH = 64K

While the RAM region is designed for data, it generally keeps execution permissions, so sections of code can be loaded into RAM and executed at runtime. Executing code in RAM expands the flexibility of the system, allowing us to process code sections before loading them to memory. Binaries that are not meant to be executed in place can be stored on any device in other formats too, even using compression or encryption algorithms. While sometimes handy, the possibility of using sections in RAM to store executable code takes away precious runtime memory from a system. The benefits must be carefully taken into account beforehand when designing the system, especially from the point of view of actual runtime memory demands coming from the application.

Peripheral-access regions

The 512 MB area following the internal RAM region, starting at address 0x40000000, is reserved for peripherals that are normally built into a microcontroller. The 1 GB area starting at address 0xA0000000 is instead used to map external memory chips and other devices that can be memory-mapped in the MCU addressing space but are not part of the original chip package. In order to correctly access the peripherals, the configuration of the internal components within the MCU packaging and the addresses of the memory-mapped devices must be known in advance. Code execution is never allowed in these regions.

The system region

The highest 512 MB of the Cortex-M memory mapping is reserved for accessing system configuration and private control blocks. This region contains the system control registers, which are the registers used to program the processor, and the peripheral control registers, used to configure devices and peripherals. Code execution is not allowed, and the region is uniquely accessible when the processor is running at privileged level, as explained in more detail in Chapter 10, Parallel Tasks and Scheduling.

Accessing hardware registers by de-referencing their well-known addresses is useful to set and get their values at runtime. However, there is no way for the compiler to tell the difference between an assignment of a variable mapped in RAM and a configuration register in the system control block. For this reason, the compiler often thinks that it is a good idea to optimize code by altering the order of the memory transactions, which might in fact result in unpredictable effects when the next operation depends on the correct conclusion of all the memory transfer from the previous ones. For this reason, extra care is needed when accessing configuration registers to ensure that the memory transfer operation is concluded before the next one is executed.

Order of memory transactions

On ARM CPUs, the memory system does not guarantee that the memory transactions are executed in the same order as the instructions that generate them. The order of memory transactions can be altered to adjust to the characteristics of the hardware, such as the wait states required to access underlying physical memory, or by the speculative branch prediction mechanisms implemented at the microcode level. While Cortex-M microcontrollers guarantee a strict ordering of the transactions involving the peripherals and the system regions, in all other cases code must be instrumented accordingly, by placing adequate memory barriers to ensure that the previous memory transactions have been executed before executing the next instruction. The Cortex-M instruction set includes three kinds of barriers:

• The data memory barrier (DMB)
• The data synchronization barrier (DSB)
• The instruction synchronization barrier (ISB)

The DSB is a soft barrier, invoked to ensure that all the pending transactions are executed before the next memory transaction occurs. The DSB is used to actually suspend the execution until all the pending transactions have been executed. The ISB, in addition, also flushes the CPU pipeline and ensures that all the new instructions are fetched again after the memory transactions, thus preventing any side effects caused by the outdated memory content. There are a number of cases where using a barrier is required:

• After updating the VTOR to change the address of the IV
• After updating the memory mapping
• During the execution of code that modifies itself

The execution stack

As seen in the previous chapter, a bare-metal application starts executing with an empty stack area. The execution stack grows backward, from the high address provided at boot to lower addresses every time a new item is stored. The stack keeps track of the chain of function calls at all times by storing the branching point at each function call, but it also serves as temporary storage during function executions. Variables within the local scope of each function are stored inside the stack while the function is executing. For this reason, keeping stack usage under control is one of the most critical tasks while developing an embedded system.

Embedded programming requires us to be aware at all times of stack usage while coding. Placing big objects in the stack, such as communication buffers or long strings, is in general not a good idea, considering that the space for the stack is always very limited. The compiler can be instructed to produce a warning every time the stack space required by a single function exceeds a certain threshold, as, for example, in this code:

void function(void)
{
   char buffer[200];
   read_serial_buffer(buffer);
}

If compiled with the GCC option, -Wstack-usage=100, it will produce the following warning:

main.c: In function 'function':
main.c:15:6: warning: stack usage is 208 bytes [-Wstack-usage=]

This can be intercepted at compile time.

While this mechanism is useful to identify local stack overuses, it is not effective to identify all the potential stack overflows in the code, as the function calls may be nested and their stack usage added up. Our function uses 208 bytes of the stack whenever it is invoked, 200 to host the buffer local variable in the stack, and 8 additional bytes to store two pointers: the origin of the call in the code section, which is stored as a return point, and the frame pointer, which contains the old location of the stack pointer before the call.

By design, the stack grows every time a function is called and shrinks again when functions return. In a given case, it is particularly difficult to make estimations about the runtime stack usage, which is the purpose of recursive functions. For this reason, the use of recursion in the code should be avoided whenever possible, or reduced to the minimum and kept under strict control otherwise, knowing that the memory area reserved for the stack in the target is small:

Figure 5.2 – The stack pointer moves down when a function is called to store frame pointers and local variables

Stack placement

The initial pointer to the stack area can be selected at boot by setting the desired memory address in the first word of the IV table, which corresponds to the beginning of the binary image loaded in flash.

This pointer may be set at compile time, in different ways. The simple example from Chapter 4, The Boot-Up Procedure, shows how it is possible to assign a specific area for the stack or use symbols exported from the linker script.

Using the linker script as a central point to describe memory regions and segments makes the code more portable across similar platforms.

Since our STM32F407 provides an additional, tightly coupled 64-KB memory bank at address 0x10000000, we may want to reserve its lower 16 KB for the execution stack and keep the rest in a separate section for later use. The linker script must define the region on top, in the MEMORY block:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 1M
  SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
  CCRAM(rwx) : ORIGIN = 0x10000000, LENGTH = 64K
}

Two symbols may now be exported at the end of the file, by assigning constant, pre-defined values:

_stack_size = 16 * 1024;
_stack_end = ORIGIN(CCRAM) + _stack_size;

The values of _stack_size and _stack_end can be accessed by the application as ordinary C symbols. _stack_end is placed at address 0 when the vector table is initialized to indicate the highest stack address:

__attribute__ ((section(".isr_vector")))
void (* const IV[])(void) =
{
  (void (*)(void))(&_end_stack),
  isr_reset, // Reset
  isr_fault, // NMI
  isr_fault, // HardFault
  /* more interrupt routines follow */

Whenever possible, it is a good idea to delegate a separate memory region to the stack area, as in this case. Unfortunately, this is not possible on all platforms.

Most embedded devices with physical memory mapping offer a single continuous mapping region for the entire RAM. A common strategy used to organize the memory in these cases is to place the initial stack pointer at the highest available address at the end of the mappable memory. This way, the stack is free to grow from the top of the memory down, while the application can still use the memory to allocate dynamic objects from the lowest address that is not used by any other section. While this mechanism is considered the most efficient, giving the illusion that it is possible to use up every last byte of RAM available, it is dangerous because the two areas growing in opposite directions may collide, leading to unpredictable results.

Stack overflows

The main problem with stack sizing and placement is that it is very difficult, if not impossible, to recover from a situation of stack overflow in a single-thread, bare-metal application. When the stack is self-contained in its own physical region, such as a separate memory bank, if its lower bound is a region not mapped to any device, a stack overflow will cause a hard fault exception, which can be trapped to halt the target.

In other cases, such as when adjacent memory is used for other purposes, the stack pointer might overflow into other segments, with a concrete risk of corrupting other memory areas, with catastrophic consequences including even opening the door to malicious code injections and arbitrary code execution attacks on the target. The best strategy usually consists of assigning adequate stack space at boot, isolating the stack as much as possible from the other memory sections, and checking the stack usage at runtime. Configuring the stack to use the lowest available addresses in RAM ensures that a stack overflow will result in a hard fault, rather than accessing valid pointers in adjacent areas in memory. The most classic approach for a bare-metal system with a single contiguous region of memory-mapped RAM is putting the initial stack pointer at the highest address available and having it grow backward toward lower addresses. The linker script exports the highest address mapped as the initial stack pointer:

_end_stack = ORIGIN(RAM) + LENGTH(RAM);

The available memory between the end of the .bss section and the lowest address in the stack may be used for dynamic allocations by the application, and at the same time, the stack is allowed to grow in the opposite direction. This is an efficient way to utilize all the available memory because the stack does not require a lower boundary, but it is safe only as long as the total amount of memory used from both sides fits inside the designated areas. If the sections are allowed to dynamically grow toward higher addresses, there is always a possibility of collisions if there is overlap from both sides:

Figure 5.3 – Heap allocations and the execution stack growing in opposite directions

Collisions between two contiguous memory areas are very common and dangerous events in embedded systems with one single continuous region of memory. A solution proposed later in this chapter, in the Memory protection unit section, can be used to separate memory into two logical blocks by inserting a third inaccessible block in the middle and to help identify and intercept these cases.

Stack painting

An effective way to measure the amount of stack space needed at runtime consists of filling the estimated stack space with a well-known pattern. This mechanism, informally referred to as stack painting, reveals the maximum expansion of the execution stack at any time. By running the software with a painted stack, it is in fact possible to measure the amount of stack used by looking for the last recognizable pattern, and assuming that the stack pointer has moved during the execution, but never crossing that point.

We can perform stack painting manually in the reset handler, during memory initialization. To do so, we need to assign an area to paint. In this case, it would be the last 8 KB of memory up until _end_stack. Once again, while manipulating the stack in the reset_handler function, local variables should not be used. The reset_handler function will store the value of the current stack pointer in the sp global variable:

static unsigned int sp;

Within the handler, the following section can be added before invoking main():

asm volatile("mrs %0, msp" : "=r"(sp));
dst = ((unsigned int *)(&_end_stack)) – (8192 / sizeof(unsigned int)); ;
while (dst < sp) {
   *dst = 0xDEADC0DE;
   dst++;
}

The first assembly instruction is used to store the current value of the stack pointer to the sp variable, ensuring that the painting stops after the area is painted but only up until the last unused address in the stack:

Figure 5.4 – Painting the stack area with a recognizable pattern helps to estimate the stack memory used in the prototype

The current stack usage can be checked periodically at runtime – for instance, in the main loop – to detect the area painted with the recognizable pattern. The areas that are still painted have never been used by the execution stack so far and indicate the amount of stack still available.

This mechanism may be used to verify the amount of stack space required by the application to run comfortably. According to the design, this information can be used later on to set a safe lower limit on the segment that can be used for the stack. Stack painting, however, is not always effective, as it gives a measurement of the stack used during the execution, but it might overlook corner cases where the stack usage may be bigger. Increasing test coverage while keeping an eye on the stack painting at the end of each test may help to allocate the appropriate amount of stack space during the development phase.

Heap management

Safety-critical embedded systems are often designed not to implement any dynamic memory allocation. While this may sound extreme, it minimizes the impact of the most common programming mistakes in the application code, which might lead to catastrophic consequences for the running system.

On the other hand, dynamic allocation is a powerful tool because it gives complete control over the lifetime and the size of the memory blocks. Many third-party libraries designed for embedded devices expect an existing implementation of dynamic memory allocation. Dynamic memory is managed through a heap structure in memory, by keeping track of the status and the size for each allocation, incrementing the pointer to the next area of free memory, and reusing blocks that have been freed if new allocation requests are processed.

A standard programming interface for heap allocation consists of two basic functions:

void *malloc(size_t size);
void free(void *ptr);

These function signatures are defined by the ANSI-C standard and are commonly found in operating systems. They allow us to request a new memory area of a given size and free up the previously allocated area referred to by the specified pointer respectively. More complete heap management has support for an additional call, realloc, that allows us to resize a memory area previously allocated, either in place or by relocating it to a new segment that is large enough to contain an object of the given size:

void *realloc(void *ptr, size_t size);

While realloc is generally left out from most of the embedded system implementations, it may be useful in some cases to resize objects in memory.

Depending on the implementation, memory management could be more or less efficient in joining together contiguous blocks that had been freed, in order to create larger available segments without having to allocate new space. Real-time operating systems usually offer allocators with different heap management. To mention one, FreeRTOS provides five different portable heap managers to choose from.

If we opt for a solution that allows for dynamic allocations, it is important to design it while taking into account a few important factors:

• The geometry of the regions where the heap is placed
• The higher boundary of the section dedicated to the heap, if it is shared with the stack, to prevent heap-stack collisions
• The policy to adopt if there is not enough memory to satisfy requests for new allocations
• How to deal with memory fragmentation and keep the overhead of unused blocks as small as possible
• Using separate pools to separate the memory used by specific objects and modules
• Spreading a single pool of memory across non-contiguous regions

When no allocator is available on the target – for example, if we are developing a bare-metal application from scratch – we might be required to implement an allocator that responds to the characteristics of the design. This can be done either from scratch by providing a custom implementation of the malloc/free functions or using implementations provided by the C library in use. The first approach gives complete control over the fragmentation, memory areas, and pools to be used to implement the heap, while the latter hides most of the handling while still allowing customization of the (contiguous) memory area and boundaries. In the next two sections, we will explore the two possible strategies in more detail.

Custom implementation

Unlike servers and personal computers, where memory allocations are handled using pages of a specific size, in bare-metal embedded systems, the heap is usually one or more contiguous areas of physical memory that can be divided internally using any alignment. Building heap-based memory allocation based on the malloc/free interface consists of keeping track of the requested allocations in memory. This is usually done by attaching a small header in front of each allocation to track the state and the size of the allocated section, which can be used in the free function to validate the allocated block and make it available for the next allocation. A basic implementation, providing dynamic memory starting from the first available address after the end of the .bss section, might represent each block in memory using a preamble, such as the following:

struct malloc_block {
  unsigned int signature;
  unsigned int size;
};

Two different signatures can be assigned to identify valid blocks and differentiate blocks still in use versus blocks that have already been freed:

#define SIGNATURE_IN_USE (0xAAC0FFEE)
#define SIGNATURE_FREED (0xFEEDFACE)
#define NULL (((void *)0))

The malloc function should keep track of the highest address in the heap. In this example, a static variable is used to mark the current end of the heap. This is set to the start address at the beginning and will grow every time a new block is allocated:

void *malloc(unsigned int size)
{
  static unsigned int *end_heap = 0;
  struct malloc_block *blk;
  char *ret = NULL;
  if (!end_heap) {
    end_heap = &_start_heap;
  }

The next two lines ensure that the block requested is 32-bit-aligned to optimize the access to malloc_block:

 if (((size >>2) << 2) != size)
   size = ((size >> 2) + 1) << 2;

The malloc function then first looks in the heap for a memory section that has been previously freed:

 blk = (struct malloc_block *)&_start_heap;
 while (blk < end_heap) {
   if ((blk->signature == SIGNATURE_FREED) &&
        (blk->size >= size)) {
     blk->signature = SIGNATURE_IN_USE;
     ret = ((char *)blk) + sizeof(struct malloc_block);
     return ret;
   }
   blk = ((char *)blk) + sizeof(struct malloc_block) +
       blk->size;
   }

If no available slot is found, or if none of them is large enough to satisfy the size required for the allocation, the memory is allocated at the end of the stack and the pointer is updated accordingly:

   blk = (struct malloc_block *)end_heap;
   blk->signature = SIGNATURE_IN_USE;
   blk->size = size;
   ret = ((char *)end_heap) + sizeof(struct malloc_block);
   end_heap = ret + size;
   return ret;
 }

In both cases, the address returned hides the malloc_block control structure that precedes it. The end_heap variable always points to the end of the last block allocated in the heap, but it is not an indication of the memory used, as intermediate blocks may have been freed in the meanwhile. This example free function, demonstrating a very simple case, is only performing basic checks on the block that needs to be freed and setting the signature to indicate that the block is no longer being used:

void free(void *ptr)
{
  struct malloc_block *blk = (struct malloc_block *)
        (((char *)ptr)-sizeof(struct malloc_block));
  if (!ptr)
    return;
  if (blk->signature != SIGNATURE_IN_USE)
    return;
  blk->signature = SIGNATURE_FREED;
}

Although this example is very simplistic, it aims at explaining the basic functionality of heap allocation without taking into account all real-life constraints and limitations. In fact, allocating and freeing objects of different sizes may cause fragmentation. To minimize the impact of this phenomenon in terms of memory usage and wasted space between active allocations, the free function should at least implement some kind of mechanism to join together adjacent areas that are no longer in play. Furthermore, the preceding example, malloc, assumes that the heap section does not have an upper boundary, does not perform any check on the new location of the end_heap pointer, and does not define a strategy when there is no memory available to allocate.

Although toolchains and libraries often provide a default implementation of malloc and free, implementing custom heap-based allocation mechanisms still makes sense in cases where the implementations available do not meet the requirements – for example, if we want to manage separate memory pools or merge separate physical memory sections to use them in the same pool.

Fragmentation issues cannot be completely resolved on systems with physical memory mapping because it is impossible to move around previously allocated blocks to optimize the space available. The issue can, however, be mitigated by keeping the number of allocations under control, reusing allocated blocks as much as possible, and avoiding frequent calls to malloc/free, especially to request blocks with different sizes.

The use of dynamic memory, regardless of the implementation, introduces a number of safety concerns and should be avoided in all life-critical systems, and in general wherever it is not required. Simpler, single-purpose embedded systems can be designed to avoid the use of dynamic memory allocations altogether. In these cases, a simple malloc interface can be provided to allow permanent allocations during startup.

Using newlib

Toolchains may provide a set of utilities, which often include dynamic memory allocation mechanisms. GCC-based toolchains for microcontrollers include a reduced set of standard C calls, usually in the built-in standard C library. A popular choice, often included in the ARM-GCC embedded toolchain, is newlib. While providing the implementation of many standard calls, newlib remains as flexible as possible by allowing customization of the operations involving the hardware. The newlib library can be integrated into both single-thread, bare-metal applications and in a real-time operating system, provided that the required system calls are implemented.

In the case of malloc, newlib requires an existing implementation of the sbrk function. This function is expected to move the heap pointer forward every time a new allocation requires an extension of the heap space and return the old value of the heap to malloc, in order to complete allocations every time an existing, previously freed, and reusable block is not found in the pool:

Figure 5.5 – newlib implements malloc and free and relies on an existing implementation of _sbrk

A possible implementation of the _sbrk function may be the following:

void * _sbrk(unsigned int incr)
{
  static unsigned char *heap = NULL;
  void *old_heap = heap;
  if (((incr & 0x03) != incr)
    incr = ((incr >> 2) + 1) << 2;
  if (old_heap == NULL)
    old_heap = heap = (unsigned char *)&_start_heap;
  heap += incr;
  return old_heap;
}

If the code is linked without the -nostdlib flag, the malloc and free functions, if invoked anywhere in the code, will be automatically found within the newlib library built in the toolchain and included in the final binary. Failing to define an _sbrk symbol, in this case, will result in a linking error.

Limiting the heap

In all the allocation functions seen so far, there is no limit imposed by the software on the amount of memory reserved for the heap. While overflowing the stack is often hard to prevent, and extremely difficult to recover from, running out of available heap memory can more often be gracefully handled by the application – for example, by canceling or postponing the operation that required the allocation. In more complex multithreaded systems, an operating system could actively react to the memory shortage by terminating non-vital processes to free up memory for new allocations. Some advanced systems using page-swapping mechanisms, such as Linux, may implement overcommit on the available memory. This mechanism guarantees that memory allocations never fail, and malloc will never return NULL to indicate a failure.

Memory-consuming processes in a system may be instead terminated at any time by a kernel thread, the out-of-memory killer, to make space for new allocations from other less resource-consuming processes. On an embedded system, especially if there is no multithreading, the best choice is to have the allocator return NULL when there is no physical space left on the heap so that the system can keep running and the application can possibly recover by recognizing the out-of-memory episode. The section in memory dedicated to the heap can be limited by exporting the address for its upper boundary in the linker script, as shown here:

_heap_end = ORIGIN(RAM) + LENGTH(RAM);

The backend for the newlib library malloc implementation can account for the newly introduced upper bound in the _sbrk() function:

void * _sbrk(unsigned int incr) {
  static unsigned char *heap = NULL;
  void *old_heap = heap;
  if (((incr & 0x03) != incr)
    incr = ((incr >> 2) + 1) << 2;
  if (old_heap == NULL)
    old_heap = heap = (unsigned char *)&_start_heap;
  if ((heap + incr) >= &_end_heap)
    return (void *)(-1);
  else
    heap += incr;
  return old_heap;
}

The special (void *)(-1) value that is returned by sbrk in case of memory shortage for heap allocation indicates to the calling malloc that there is not enough space to perform the requested allocation. malloc will then return NULL to the caller.

It is very important in this case that the caller always checks the return value at each invocation of malloc() and that the application logic is able to correctly detect that the system is out of memory, and react in an attempt to recover from it.

Multiple memory pools

In some systems, it is useful to keep separate sections as dynamic memory heaps, each dedicated to a specific function in the system. Heap allocation mechanisms using separate pools may be implemented for different reasons, such as ensuring that specific modules or subsystems do not use more memory than the amount that is assigned to them at compile time, or ensuring that allocations with the same size can reuse the same physical space in memory, reducing the impact of fragmentation, or even assigning a pre-defined, fixed area in memory for DMA operations with peripherals or network devices. It is possible to delimit the sections for the different pools by, as usual, exporting symbols in the linker script. The following example pre-allocates the space in memory for two pools, of 8 KB and 4 KB respectively, located at the end of the .bss section in RAM:

PROVIDE(_start_pool0 = _end_bss);
PROVIDE(_end_pool0 = _start_pool0 + 8KB);
PROVIDE(_start_pool1 = _end_pool0);
PROVIDE(_end_pool1 = _start_pool1 + 4KB);

A custom allocation function must be defined, since the malloc interface does not support the selector of the pool, but the functions can be made generic for both pools. A global structure can be populated with the values exported by the linker:

struct memory_pool {
  void *start;
  void *end;
  void *cur;
};
static struct memory_pool mem_pool[2] = {
  {
    .start = &_start_pool0;
    .end = &_end_pool0;
  },
  {
    .start = &_start_pool1;
    .end = &_end_pool1;
  },
};

The function must take an extra argument to specify the pool. Then, the allocation is performed with the same algorithm, only changing the current pointer and the boundaries of the selected pool. In this version, the out-of-memory errors are detected before moving the current heap value forward, returning NULL to notify the caller:

void *mempool_alloc(int pool, unsigned int size)
{
  struct malloc_block *blk;
  struct memory_pool *mp;
  char *ret = NULL;
  if (pool != 0 && pool != 1)
    return NULL;
  mp = mem_pool[pool];
  if (!mp->cur)
    mp->cur = mp->start;
  if (((size >>2) << 2) != size)
    size = ((size >> 2) + 1) << 2;
  blk = (struct malloc_block *)mp->start;
  while (blk < mp->cur) {
    if ((blk->signature == SIGNATURE_FREED) &&
          (blk->size >= size)) {
      blk->signature = SIGNATURE_IN_USE;
      ret = ((char *)blk) + sizeof(struct malloc_block);
      return ret;
    }
    blk = ((char *)blk) + sizeof(struct malloc_block) +
           blk->size;
  }
  blk = (struct malloc_block *)mp->cur;
  if (mp->cur + size >= mp->end)
    return NULL;
  blk->signature = SIGNATURE_IN_USE;
  blk->size = size;
  ret = ((char *)mp->cur) + sizeof(struct malloc_block);
  mp->cur = ret + size;
  return ret;
}

Once again, this mechanism does not account for memory fragmentation, so the mempool_free function can have the same implementation as free for the simplified malloc, as the only necessary thing to do is to mark the blocks being freed as unused.

In more complete cases, where free or a separate garbage collector routine takes care of merging contiguous freed blocks, it might be required to keep track of the freed blocks in each pool, in a list, or in another data structure that can be visited to check whether merging is possible.

Common heap usage errors

The use of dynamic memory allocation is considered unsafe in some environments, as it is widely known to be the source of nasty bugs, which are in general both critical and very hard to identify and fix. Dynamic allocations may be difficult to track, especially when code grows in size and complexity and there are many dynamically allocated data structures. This is already very serious in multithreaded environments, where it is still possible to implement fallback mechanisms, such as terminating a misbehaving application, but it becomes critical on single-threaded embedded systems, where these kinds of errors are often fatal for the system. The most common types of errors when programming with heap allocations are as follows:

• NULL pointer de-reference
• Double free
• Use after free
• Failure to call free, resulting in memory leaks

Some of these can be avoided by following a few simple rules. malloc returns the value that should always be checked before using the pointer. This is particularly important in environments where resources are limited, and the allocator can return NULL pointers to indicate that there is no memory available for the allocation. The preferred approach is ensuring that there is a defined strategy to follow when the required memory is not available. In any case, all dynamic pointers must be checked to ensure that they do not point to a NULL value before attempting to de-reference.

Freeing NULL pointers is a legal operation that must be identified when free is called. By including a check at the beginning of the function, if the pointer is NULL, no action is performed and the call is ignored.

Immediately after, we can also check that the memory has not been freed before. In our free function, we implement a simple check against the signature of the malloc_block structure in memory. It would be possible to add a log message, or even a breakpoint, to debug the origin of the second free function:

if (blk->signature != SIGNATURE_IN_USE) {
  /* Double free detected! */
  asm("BKPT #0") ;
  return;
}

Unfortunately, this mechanism may only work in some cases. In fact, if the block that was previously freed is assigned again by the allocator, it would be impossible to detect further uses of its original reference, and a second free would cause the second reference to be lost as well. For the same reason, use-after-free errors are hard to diagnose, as there is no way to tell that a freed memory block has been accessed again. It is possible to paint freed blocks with a recognizable pattern so that if the content of the block is altered after free has been called, the next invocation of malloc on that block can detect the alteration. However, this again does not guarantee detection of all the cases and only works for write accesses to a freed pointer; additionally, this would not be able to identify all the cases where freed memory is accessed for reading.

Memory leaks are easy to diagnose but sometimes difficult to locate. With limited resources, it is often the case that forgetting to free allocated memory uses up all the available heap very quickly. While there are techniques used to track down allocations, it is often sufficient to break into the software with the debugger and look for repeated allocations of the same size to track down the buggy caller.

In conclusion, due to their catastrophic and hideous nature, dynamic memory bugs may be one of the biggest challenges on embedded systems. Therefore, writing safer application code is often less expensive in terms of resources than hunting for memory bugs at the system level – for example, instrumenting the allocator. Analyzing the lifetime of each allocated object thoroughly, and making the logic as clear and readable as possible, can prevent most of the problems related to pointer handling and save a lot of time that would otherwise be spent debugging.

The memory protection unit

In a system without virtual address mapping, it is harder to create a separation between sections that can be accessed by the software at runtime. The memory protection unit, often referred to as the MPU, is an optional component present in many ARM-based microcontrollers. The MPU is used to separate sections in memory by setting local permissions and attributes. This mechanism has several uses in real-life scenarios, such as preventing access to memory when the CPU is running in user mode, or preventing fetching code from being executed from writable locations in RAM. When the MPU is enabled, it enforces the rules by triggering a memory exception interrupt when those rules are violated.

While commonly used by operating systems to create process stack separation and enforce privileged access to system memory, the MPU can be useful in a number of other cases, including bare-metal applications.

MPU configuration registers

In the Cortex-M, the control block region related to MPU configuration is located in the system control block, starting at address 0xE000ED90. Five registers are used to access the MPU:

• The MPU Type Register (offset 0x00) contains information about the availability of the MPU system and the number of regions supported. This register is also available on systems without an MPU to indicate that the functionality is not supported.
• The MPU Control Register (offset 0x04) is used to activate the MPU system and enable the default background mapping for all the regions that are not explicitly mapped in the MPU. If background mapping is not enabled, accessing non-mapped regions is not allowed.
• The MPU Region Number Register (RNR offset 0x08) is used to select the region to configure.
• The MPU Region Base Address Register (RBAR offset 0x0C) can be accessed to change the base address of the selected region.
• The MPU Region Attribute and Size Register (RASR offset 0x10) defines the permissions, attributes, and size of the selected region.

Programming the MPU

The MPU of Cortex-M microcontrollers supports up to eight different programmable regions. A function that enables the MPU and sets up all the regions can be implemented and invoked at the beginning of program. The MPU registers are mapped in HAL libraries, but in this case, we are going to define our own version and access them directly:

#define MPU_BASE 0xE000ED90
#define MPU_TYPE (*(volatile uint32_t *)(MPU_BASE + 0x00))
#define MPU_CTRL (*(volatile uint32_t *)(MPU_BASE + 0x04))
#define MPU_RNR (*(volatile uint32_t *)(MPU_BASE + 0x08))
#define MPU_RBAR (*(volatile uint32_t *)(MPU_BASE + 0x0c))
#define MPU_RASR (*(volatile uint32_t *)(MPU_BASE + 0x10))

In our example, we used the following defined bit-field value definitions to set the right attributes in RASR:

#define RASR_ENABLED (1)
#define RASR_RW (1 << 24)
#define RASR_RDONLY (5 << 24)
#define RASR_NOACCESS (0 << 24)
#define RASR_SCB (7 << 16)
#define RASR_SB (5 << 16)
#define RASR_NOEXEC (1 << 28)

The possible sizes, which should end up in the size field of RASR in bits 1:5, are coded as follows:

#define MPUSIZE_1K (0x09 << 1)
#define MPUSIZE_2K (0x0a << 1)
#define MPUSIZE_4K (0x0b << 1)
#define MPUSIZE_8K (0x0c << 1)
#define MPUSIZE_16K (0x0d << 1)
#define MPUSIZE_32K (0x0e << 1)
#define MPUSIZE_64K (0x0f << 1)
#define MPUSIZE_128K (0x10 << 1)
#define MPUSIZE_256K (0x11 << 1)
#define MPUSIZE_512K (0x12 << 1)
#define MPUSIZE_1M (0x13 << 1)
#define MPUSIZE_2M (0x14 << 1)
#define MPUSIZE_4M (0x15 << 1)
#define MPUSIZE_8M (0x16 << 1)
#define MPUSIZE_16M (0x17 << 1)
#define MPUSIZE_32M (0x18 << 1)
#define MPUSIZE_64M (0x19 << 1)
#define MPUSIZE_128M (0x1a << 1)
#define MPUSIZE_256M (0x1b << 1)
#define MPUSIZE_512M (0x1c << 1)
#define MPUSIZE_1G (0x1d << 1)
#define MPUSIZE_2G (0x1e << 1)
#define MPUSIZE_4G (0x1f << 1)

The first thing to do when we enter the mpu_enable function is to ensure that the feature is available on our target, by checking the MPU_TYPE register:

int mpu_enable(void)
{
  volatile uint32_t type;
  volatile uint32_t start;
  volatile uint32_t attr;
  type = MPU_TYPE;
  if (type == 0) {
    /* MPU not present! */
    return -1;
  }

In order to configure the MPU, we must ensure that it is disabled while we change the base addresses and the attributes of each region:

  MPU_CTRL = 0;

The flash region that contains the executable code can be marked as read-only region 0. The values for the RASR attributes are as follows:

  start = 0;
  attr = RASR_ENABLED | MPUSIZE_256K | RASR_SCB |
       RASR_RDONLY;
  mpu_set_region(0, start, attr);

The whole RAM region can be mapped as read-write. If we do not need to execute code from RAM, we can set the execute-never (XN) bit in the region attributes. RAM is mapped as region 1 in this case:

  start = 0x20000000;
  attr = RASR_ENABLED | MPUSIZE_64K | RASR_SCB | RASR_RW 
      | RASR_NOEXEC;
  mpu_set_region(1, start, attr);

Since memory mapping is processed in the same order as memory region numbers, we can use region 2 to create an exception within region 1. Regions with higher numbers have priority over regions with lower numbers, so exceptions can be created within an existing mapping with a lower number.

Region 2 is used to define a guard region as a lower boundary for the stack growing backward, the purpose of which is to intercept stack overflows. In fact, if at any moment the program tries to access the guard region, it triggers an exception and the operation fails. In this case, the guard region occupies 1 KB at the bottom of the stack. It has no access permissions configured in its attributes. The MPU ensures that the region is not accessible at runtime:

  start = (uint32_t)(&_end_stack) - (STACK_SIZE + 1024);
  attr = RASR_ENABLED | MPUSIZE_1K | RASR_SCB |
  RASR_NOACCESS | RASR_NOEXEC;
  mpu_set_region(2, start, attr);

Finally, we describe the system area as a read-write, non-executable, and non-cacheable area so that the program will still be able to access the system registers after the MPU has been activated again. We use region 3 for this:

  start = 0xE0000000;
  attr = RASR_ENABLED | MPUSIZE_256M | RASR_SB
  RASR_RW | RASR_NOEXEC;
  mpu_set_region(3, start, attr);

As a final step, we enable the MPU again. The MPU will allow us to define a background region, setting the default permissions for those areas that are not covered in the active region configurations. In this case, the absence of a definition for a background policy results in prohibited access to all the areas that are not explicitly mapped:

  MPU_CTRL = 1;
  return 0;
}

The helping function that sets the starting address and the attributes for the memory regions looks like the following:

static void mpu_set_region(int region, uint32_t start, uint32_t attr)
{
  MPU_RNR = region;
  MPU_RBAR = start;
  MPU_RNR = region;
  MPU_RASR = attr;
}

The value used to set attributes and sizes in MPU_RASR in this example is defined according to the structure of the register itself. MPU_RASR is a bit-field register, containing the following fields:

• Bit 0: The enable/disable region.
• Bits 1:5: The size of the partition (see the special values to assign to this field).
• Bits 16:18: Indicate whether the memory is bufferable, cacheable, and shared, respectively. Devices and system registers should be marked as non-cacheable at all times to guarantee the strict order of the transaction, as explained at the beginning of this chapter.
• Bits 24:26: Access permissions (read/write), separated for user and supervisor mode.
• Bit 28: Disable execution (the XN flag).

It is now possible to write a program that overflows the stack and see the difference in the debugger when the mpu_enable function is called and when it is not. If the MPU is available on the target, it is now able to intercept stack overflows, triggering an exception in the CPU:

Figure 5.6 – The guard region is marked as inaccessible in the MPU to prevent stack overflows

The configuration we used in this case for the MPU is very strict, not allowing access to any memory, except for the regions mapping flash and RAM. The extra 1-KB guard region ensures that we can detect stack overflows at runtime. This configuration in fact introduces an artificial separation between the two regions allocated for heap and stack areas, in a physically continuous space, by introducing a block that replicates inaccessible blocks in between. Although allocations in the heap exceeding the heap limit will not directly trigger an overflow, any memory access in the guard region will cause a memory fault.

In real applications, the MPU configuration may be more complex and even change its values at runtime. In Chapter 10, Parallel Tasks and Scheduling, for example, we will explain how the MPU can be used to isolate thread address spaces in a real-time operating system.

Summary

Memory management in an embedded system is the source of the most critical bugs, and for this reason, particular attention must be dedicated to designing and implementing the correct solutions for the platform in use and application purposes. The execution stack should be carefully placed, sized, and delimited when possible.

Systems not providing dynamic allocations are safer, but embedded systems with higher complexity benefit from dynamic allocation techniques. Programmers must be aware that errors in memory handling can be critical for a system and very difficult to spot, so extra care is required when code handles dynamically allocated pointers.

The MPU can be a vital tool to enforce access permissions and attributes on memory regions, and it can be used for several purposes. In the example shown, we implemented an MPU-based mechanism to enforce a physical boundary for the stack pointer.

In the next chapter, we will examine other common components included in modern microcontrollers. We will learn how to handle clock settings, interrupt priorities, general-purpose I/O communication, and other optional features.